Android Application Development All-in-One for Dummies, 3rd Edition

IDE Screenshot Usage in Books

There are cases where it’s very tough to figure out the correct presentation of material in a book, which is made more difficult by some readers preferring one presentation and other readers another. It comes down to how people learn in many cases. Visual learners prefer screenshots, abstract learners prefer text. Of course, there are all sorts of learners between these two extremes. So, what seems like a simple question can become quite complex.

The question at hand is whether to present screenshots of an IDE in a book with the associated example code and its output. The problem is that vendors now assume that developers have very large displays and so have made use of all of that extra screen real estate. In addition, book publishers don’t want books where a single image consumes an entire page. The result is that it’s very hard to get a screenshot where the text is completely readable. It can be done, but the text will generally still be smaller than the print in the book. Older readers complain that they need a magnifying glass to see the text at all.

However, there are benefits to using screenshots. The most important benefit is that, even if the text isn’t completely readable, visual learners can see what their IDE should look like as they follow the progress of procedures in the book. This feedback lets the visual learner know that they are doing things correctly and are getting the correct result. Another benefit is that an example tends to stay in one piece. The graphical output of an example doesn’t end up several pages away from the source code that produces it. Sometimes, textual output is wider than the page will allow using the normal font size. So, the options are to print the output in the book at the normal font size, but in a truncated form, which means that it’s no longer complete. A screenshot can show the complete textual output, but at a smaller font. For beginner readers, the second form, while not optimal, is preferred because truncating the output produces questions in the reader’s mind.

So, how do you feel about IDE screenshots in books? Are they more helpful or more confusing? Part of the reason for posts like this is to get your opinion and discover more about you as a reader. Obviously, a book author wants to use the communication techniques that work best overall for everyone, book space often not allowing for the investigation of every presentation alternative. Let me know your thoughts at [email protected].

Giving Hackers an Exciting Target

Hackers will attack anyone, any organization, or anything that seems to offer the promise of something in exchange for the time spent: money, resources, revenge…the list goes on. However, for many hackers the kicker for choosing somewhere to hit is some level of challenge, some sort of excitement. After all, why attack a boring site when there is one out there literally begging you to attack it? Such is the case with GrapheneOS, which bills itself as:

The private and secure mobile operating system with Android app compatibility.
GrapheneOS Website

According to Multiple DDoS Attacks at GrapheneOS — What’s Going On Behind the Scenes?, GrapheneOS has recently endured multiple attacks. I verified the story on Twitter from a post by GrapheneOS. Such an attack can happen to anyone at any time. Keeping a low profile seems prudent, but not always possible (as is the case here). One of the things I stressed when writing Machine Learning Security Principles is that anything an organization can do to make attacks harder and less attractive will only reduce the security burden of the organization in the long run. Keeping a low profile tends to make an attack less attractive.

The reason that I was attracted to this particular DDoS attack is that GrapheneOS is using Synapse, an AI-based product. The article, Synapse Technology Corporation: Using AI to Take a Good Look at Airport Security, tells you a bit more about the history of this product. In looking at the Synapse website, you can see that they have some interesting customers, including the military and government. Oddly enough, I’m not seeing any other reports of major problems with Synapse. The problem must be with the GrapheneOS security setup.

The bottom line is that if a hacker decides to break into your organization, it’ll happen at some point no matter how good your security systems are, which means that it’s essential to combine security with monitoring and analysis of attack vectors. Keeping a low profile is essential too because hackers, like the most of the rest of us, love a good challenge. Reviewing attacks like the ones targeted at GrapheneOS can help you improve your own security setup. Let me know your thoughts on AI-based security at [email protected].

Comment and Document Updates for CI/CD

In reading about Continuous Integration/Continuous Deployment (CI/CD) I often find ways to manage the code, to get people around the code, to keep errors out of the code, and so on. It’s all about the code. Developers have, in fact, developed myriad ways to keep code size small, updated, deployed, tested, and so on to ensure that users have what they want, when the they want it (if not before). Sometimes my head spins on its axis after reading such documents because it becomes a high speed dizzying affair. It’s somehow assumed that everyone can just keep up. Except, there are new people and older people and people with lesser attention spans who can’t keep up, which is why comments and documentation are so important.

As part of the coding process, developers also need to update both comments and documentation or someone will come along and make modifications based on outdated information. Even though making such updates seems like a waste of time since everyone should be able to keep up, the truth is that these updates ultimately save time. However, the updates, when they occur (which apparently isn’t often) are often made in a haphazard manner reminiscent of an old Keystone Cops movie.

Adding a process, a workflow, to the CI/CD mill is important to ensure that everything remains in sync: code, comments, and documentation. A best practice way to accomplish this task is to add steps to every update process so that nothing is left behind. Here’s how you could approach the problem:

Perform the required code updates.
During testing, ensure that the comments within the code actually match what the code is doing. Testing and other review processes should not only look at the code, but the comments too.
Update the documentation as final testing occurs. Make sure to include these elements:
- Text
- Drawings
- Mockups
- Visual Aids
- Videos
- Any other documentation elements
Specify that any old comments/documentation are outdated using one of these approaches:
- Mark it as deprecated
- Remove it from the work area and put it in an archive
- Delete it completely
Deploy the application update. If you don’t deploy the update after these steps are done, they won’t get done. Everyone will wander off somewhere and forget all about any sort of comment or documentation update.

Obviously, the approach you end up using has to meet the requirements of your organization. It also has to be simple enough that people will actually, albeit begrudgingly, perform the work. What methods do you use to keep everything in sync at your organization? Let me know at [email protected].

Creating Sensible Error Trapping

This is an update of a post that originally appeared on May 23, 2011.

Errors in software happen. A file is missing on the hard drive or the user presses an unexpected key combination. There are errors of all shapes and sizes; expected and unexpected. The sources of errors are almost limitless. Some developers look at this vastness, become overwhelmed, and handle all errors the same way—by generating an ambiguous exception for absolutely every error that doesn’t help anyone solve anything. This is the worst case scenario that’s all too common in software today. I’ve talked with any number of people who have had to employ extreme effort just to figure the source of the exception out; many people simply give up and hope that someone has already discovered the source of the error.

At one time, error handling functionality in application development languages was so poor that it was possible to give the developer the benefit of a doubt. However, with the development tools that developers have at their disposal today, there is never a reason to provide an ambiguous “one size fits all” exception. For one thing, developers should make a distinction between the expected and the unexpected. Any expected error—a missing file for example—should be handled directly and specifically. If the application absolutely must have the file and can’t recreate it, then it should display a message saying which file is missing, where it is missing from, and possibly how to obtain another copy.

Even more than simply shoving the burden onto the user, however, modern applications have significantly more resources available for handling the error automatically. For example, it’s quite possible to use an Internet connection to access the vendor’s Web site and automatically download a missing application file. Except to tell the user what’s happening when the repair will take a few minutes, the application shouldn’t even bother the user with this particular kind of error—the repair should be automatic.

All of my essential programming books include at least mentions of error handling, debugging, exceptions, and other tasks associated with running code efficiently and smoothly. For example, Part IV of C++ All-In-One for Dummies, 4th Edition is devoted to the topic of debugging. Part V Chapter 3 of this same book talks about exceptions. If you’re a C# developer, C# 10.0 All-in-One for Dummies discusses exception handling in Book I Chapter 9. Book IV Chapter 2 discusses how to use the debugger to find errors. The point is that it’s essential to handle errors in your applications in a manner that makes sense to the users who rely on the application daily and the developers who maintain it.

Note that many of my newer books provide instructions for working with online IDEs, most especially Google Colab. These online IDEs rarely provide built-in debugging functionality, so then you need to resort to other means, such as those expressed in Debugging in Google Colab notebook.

Exceptional conditions do occur. However, even in these situations the developer must avoid the generic exception at all costs. If an application experiences an unexpected error and there isn’t any way to recover from it automatically, the user requires as much information as possible about the error in order to fix it. This means that the application should diagnose the problem as much as possible. Don’t tell the user that the application simply has to end—there is never a good reason to include this sort of message. Instead, tell the user that the application can’t locate a required resource and specify the resource in as much detail as possible. If possible, let the user fix the resource access problem and then retry access before you simply let the application die an ignoble death. Remember this! Any exception that your application displays means that you’ve failed as a developer to locate and repair the errors, so exceptions should be reserved for truly exceptional conditions.

Not everyone agrees with my approach to error trapping, but I have yet to hear a convincing argument to provide unreliable, non-specific error trapping in an application. Poor error trapping always translates into increased user dissatisfaction, increased support costs, and a reduction in profitability. Let me know your thoughts on the issue of creating a sensible error trapping strategy at [email protected].

Creating Useful Comments

This is an update of a post that originally appeared on November 21, 2011.

A major problem with most applications today is that they lack useful comments. It’s impossible for anyone to truly understand how an application works unless the developer provides comments at the time the code is written. In fact, this issue extends to the developer. A month after someone writes an application, it’s possible to forget the important details about it. In fact, for some of us, the interval between writing and forgetting is even shorter. Despite my best efforts and those of many other authors, many online examples lack any comments whatsoever, making them nearly useless to anyone who lacks time to run the application through a debugger to discover how it works.

Good application code comments help developers of all stripes in a number of ways. As a minimum, the comments you provide as part of your application code provides these benefits.

Debugging: It’s easier to debug an application that has good comments because the comments help the person performing the debugging understand how the developer envisioned the application working.
Updating: Anyone who has tried to update an application that lacks comments knows the pain of trying to figure out the best way to do it. Often, an update introduces new bugs because the person performing the update doesn’t understand how to interact with the original code.
Documentation: Modern IDEs often provide a means of automatically generating application documentation based on the developer comments. Good comments significantly reduce the work required to create documentation and sometimes eliminate it altogether.
Technique Description: You get a brainstorm in the middle of the night and try it in your code the next day. It works! Comments help you preserve the brainstorm that you won’t get back later no matter how hard you try. The technique you use today could also solve problems in future applications, but the technique may become unavailable unless you document it.
Problem Resolution: Code often takes a circuitous route to accomplish a task because the direct path will result in failure. Unless you document your reasons for using a less direct route, an update could cause problems by removing the safeguards you’ve provided.
Performance Tuning: Good comments help anyone tuning the application understand where performance changes could end up causing the application to run more slowly or not at all. A lot of performance improvements end up hurting the user, the data, or the application because the person tuning the application didn’t have proper comments for making the adjustments.

The need for good comments means creating a comment that has the substance required for someone to understand and use it. Unfortunately, it’s sometimes hard to determine what a good comment contains in the moment because you already know what the code does and how it does it. Consequently, having a guide as to what to write is helpful. When writing a comment, ask yourself these questions:

Who is affected by the code?
What is the code supposed to do?
When is the code supposed to perform this task?
Where does the code obtain resources needed to perform the task?
Why did the developer use a particular technique to write the code?
How does the code accomplish the task without causing problems with other applications or system resources?

There are many other questions you could ask yourself, but these six questions are a good start. You won’t answer every question for every last piece of code in the application because sometimes a question isn’t pertinent. As you work through your code and gain experience, start writing down questions you find yourself asking. Good answers to aggravating questions produce superior comments. Whenever you pull your hair out trying to figure out someone’s code, especially your own, remember that a comment could have saved you time, frustration, and effort. What is your take on comments? Let me know at [email protected].

JavaScript and Memory Leaks

This is an update of a post that originally appeared on January 25, 2013.

I’ve written any number of books that either include JavaScript development directly or indirectly. For example, when you create a web application in C#, there is some JavaScript involved that might ruin your day unless you have some idea of what that code is doing and how it can go wrong. If you enable JavaScript on your Android phone or tablet, then you can also use JavaScript development techniques in that environment. Because JavaScript provides a well-known and standardized environment, you often find it used in places where you may not think to look, which means taking the time to actually review the code that your IDE generates for web-based applications.

One of my goals in writing a book is to introduce you to techniques that produce useful applications in an incredibly short time without writing bad code. The term bad code covers a lot of ground, but one of the more serious issues is one of memory leaks. Applications that have memory leaks will cause the application and everything else on the system to slow down due to a lack of usable memory. In addition, memory leaks can actually cause the application to crash or the system to freeze when all of the available memory is used up. So, it was with great interest that I read an LogRocket article recently entitled, How to escape from memory leaks in JavaScript. The article contains a lot of useful advice in writing good JavaScript code that won’t cause your users heartache.

One of the most important parts of this article is that it covers memory leaks as a process. There is a list of common memory leak types and how to identify them. It also introduces you to tools and techniques for fixing memory errors using Chrome DevTools.

It’s essential to know that this article doesn’t cover everything. A big one is that the memory leak you’re seeing in your application may not be due to your code—it may be caused by the browser. The potential for browser problems is an important one to keep in mind because these issues affect every application that runs, not just yours. However, when your application performs a lot of work that requires heavy memory use, the user may see your application as the culprit. It pays to track browser issues so that you can support your users properly and recommend browser updates for running your application when appropriate. For that matter, you can simply determine whether the user has one of the poorly designed browsers and tell the user to perform an update instead of running the application.

There are other potential sources of memory leaks. For example, using the wrong third party library could cause considerable woe when it comes to memory usage (amongst other issues). Consequently, you need to research any libraries or templates that you use carefully. The libraries, templates, and other tools discussed in my books are chosen with extreme care to ensure you get the best start possible in creating JavaScript applications.

One of the reasons I find JavaScript so compelling as a language is that it has grown to include enough features to create real applications that run in just about any browser on just about any platform. The ability to run applications anywhere at any time has been a long term goal of computer science and it finally seems to be a reality at a certain level. What are your thoughts on JavaScript? Let me know at [email protected].

Checking for Mobile Friendliness

This is an update of a post that originally appeared on January 6, 2016.

Is your application mobile friendly? It seems simple enough, but the answer can be very tough to come by. This whole concept of mobile device friendliness sometimes seem like an enigma wrapped in a Zen riddle. There is actually a difference between sites that are mobile friendly and those that are mobile responsive, in that a mobile responsive design does a lot more for the mobile users (and is always mobile friendly by default).

Most development tools today make a strong attempt at helping you create mobile friendly applications. In addition, new technologies and tools are helping developers create useful applications. Fortunately, vendors such as Google are now making it possible for you to verify that your site is mobile friendly with an easy to use check. All you need to do is point your browser to https://www.google.com/webmasters/tools/mobile-friendly/, enter an URL, and click Analyze. You get a quick answer to your question as shown here within a few seconds.

Verify that your site will support mobile users by performing a mobile friendly check. — Output from a Successful Mobile Friendly Check

The page contains more than just a validation of the mobile friendliness of your site. When you scroll down, you see a simulated output of your site when viewed on a smartphone. The view is important because it helps you understand how a mobile user will see your site, versus the view that you provide to desktop and tablet users. It’s important not to assume that mobile users have the same functionality as other users do. Here’s the simulated view for my site.

Mobile users may see something different than you expect, even when your site is mobile friendly. — Verify the Smartphone View of Your Site

As more and more people rely on mobile devices to access the Internet, you need to become more aware of what they’re seeing and whether they can use your site at all. According to most authorities, more users access the Internet using mobile devices today, than other devices, such as laptops, desktops, or tables. If you don’t support mobile devices correctly, you lose out on the potential audience for your site. By making the switch to mobile devices and apps, in particular, you have the ability to not only widen your audience, but you also have a better chance of being able to increase your revenue too. Most successful businesses have made the transition to mobile as they don’t want to lose any customers (but the quality of presentation varies greatly and is sometimes useless), as it may mean that they make less money than they could otherwise could from sales and that the influence of their site is far less. Let me know your thoughts about mobile device access at [email protected].

Considering the Authentication of Credit Cards in Web Settings

This is an update of a post that originally appeared on November 27, 2015.

I often write a blog post with the hope that things will change for the better at some point because there are often strategies for making things better if someone will simply implement them. I don’t know about you, but I’m buying more and more items online, which means using my credit card more often than before. That’s why articles like, How Serious a Crime Is Credit Card Theft and Fraud?, attract my attention.

One of the biggest problems is the use of static technology. For example, the Credit Verification Value (CVV), a three or four digit addition to a credit card number, is supposed to help safeguard the credit card. It doesn’t appear as part of the card data accessible through the magnetic strip or the chip. The CVV is actually printed on the card as a separate verification for venues such as web applications. The only problem is that this number is static-it remains the same for however long you own the card. Therefore, once a hacker discovers the CVV, it no longer provides any sort of security to the card owner. Interestingly enough, some sites online will sell you both credit card numbers and their associated CVV. The hackers win again.

A solution to this problem is to change the CVV periodically. Unfortunately, trying to change a printed CVV is impossible without replacing the card. One possible way to overcome this problem involves the addition of an e-paper space on the back of the card that would allow the credit card companies to change the CVV, yet keep it out of the magnetic stripe or chip. A lot of devices currently use e-paper, such as Amazon’s Kindle. The technology provides a matte paper-like appearance that reflects light similar to the way in which paper reflects it, rather than emitting light like an LED does. The difference is that e-paper is often easier to read. There is at least one company offering such a solution today as described at Gemalto Dynamic Code Card – for a more serene online shopping experience.

Oberthur (now Idemia), the inventor of the Motion Code technology used to create the updated CVV, isn’t saying too much about how the technology works. There must be an active connection between the card and a server somewhere in order to update the CVV once an hour as specified in the various articles on the topic. The only problem is in understanding how the update takes place. If the technology relies on something like a Wi-Fi or cell connection, it won’t work in rural areas where these connections aren’t available. Even so, the technology does promise to reduce the amount of fraud that currently occurs-at least, until hackers find a way to thwart it.

What is your feeling about credit card data protection? Are you a business entrusted with protecting your customers’ information? If so, maybe you should find out more here about the consulting available in this particular field of business management to ensure that you’re following the law to the letter. Does Motion Code technology actually provide a promising solution or is it another dead end? How do you deal with potential fraud when creating your applications? Send your ideas to me at [email protected].

Considering Perception in User Interface Design

This is an update of a post that originally appeared on January 24, 2014.

The original version of this article had humans seeing images in as little as 13 ms. Nothing much has really changed since then. I read a few articles recently that reminded me of a user interface design discussion I once had with a friend of mine. First, let’s discuss the articles:

The first, Everything we see is a mash-up of the brain’s last 15 seconds of visual information, says that humans can actually see something in as little as 15 ms. That short time frame provides the information the brain needs to target a point of visual focus.
The older second article, ‘Sixth Sense’ Can Be Explained by Science, explains how the sixth sense that many people relate as being supernatural in origin is actually explainable through scientific means. The brain detects a change-probably as a result of that 15 ms view-and informs the rest of the mind about it. However, the change hasn’t been targeted for closer inspection, so the viewer can’t articulate the change.
The third article, The silent “sixth” sense, is a more scientific and slightly modernized view of the second article. In short, you know the change is there, but you can’t say what has actually changed.

So, you might wonder what this has to do with website design. It turns out that you can use these facts to help focus user attention on specific locations on your site. Now, I’m not talking here about the use of subliminal perception, which is clearly illegal in many locations. Rather, it’s possible to do as a friend suggested in designing a site and change a small, but noticeable, element each time a page is reloaded. Of course, you need not reload the entire page. Technologies such as Asynchronous JavaScript And XML (AJAX) make it possible to reload just a single element as needed. (Of course, changing a single element in a desktop application is incredibly easy because nothing special is needed to do it.) The point of making this change is to cause the viewer to look harder at the element you most want them to focus on. It’s just another method for ensuring that the right area of a page or other user interface element gets viewed.

However, the articles also make for interesting thoughts about the whole issue of user interface design. Presentation is an important part of design. Your application must use good design principles to attract attention. However, these articles also present the idea of time as a factor in designing the user interface. For example, the order in which application elements load is important because the brain can perceive the difference. You might not consciously register that element A loaded some number of milliseconds sooner than element B, but subconsciously, element A attracts more attention because it registered first and your brain targeted it first. This essentially explains the difference between UX and UI, since the two are eternally intermingled in the world of development.

As science continues to probe the depths of perception, it helps developers come up with more effective ways in which to present information in a way that enhances the user experience and the benefit of any given application to the user. However, in order to make any user interface change effective, you must apply it consistently across the entire application and ensure that the technique isn’t used to an extreme. Choosing just one element per display (whether a page, window, or dialog box) to change is important. Otherwise, the effectiveness of the technique is diluted and the user might not notice it at all.

What is your take on the use of perception as a means of controlling the user interface? Do you feel that subtle techniques like the ones described in this post are helpful? Let me know your thoughts at [email protected].

Category: Android Application Development All-in-One for Dummies, 3rd Edition