How To Build An Android Application

Every platform technology uses different terminology to describe its application components. The three most important classes on the Android platform are Context, Activity and Intent. 

While there are other, more advanced, components developers can implement, these three components form the building blocks for each and every Android application. In this article, we focus on understanding how Android applications are put together. We also take a look at some handy utility classes that can help developers debug applications.

An Android application is a collection of tasks, each of which is called an activity. Each activity within an application has a unique purpose and user interface. To understand this more fully, imagine a theoretical game application called Chippy's Revenge.

Designing application features

The design of the Chippy's Revenge game is simple. It has five screens:

• Splash - This screen acts as a startup screen, with the game logo and version. It might also play some music.
• Menu - On this screen, a user can choose from among several options, including playing the game, viewing the scores, and reading the help text.
• Play - This screen is where game play actually takes place.
• Scores - This screen displays the highest scores for the game (including high scores from other players), providing players with a challenge to do better.
• Help - This screen displays instructions for how to play the game, including controls, goals, scoring methods, tips, and tricks.

Starting to sound familiar? This is the prototypical design of just about any mobile application, game or otherwise, on any platform.
Certainly, you are free to implement any kind of user interface you desire. There are no real user interface requirements on the Android platform, other than that the application must be stable, responsive and play nice with the rest of the Android system. That said, the best and most popular applications leverage the users' existing experience with user interfaces. It's best to improve upon those features, when necessary, rather than reinvent them, so you don't force the user to exert time and effort to learn your application in order to use it properly.

Determining application activity requirements

You need to implement five activity classes, one for each feature of the game:

• SplashActivity - This activity serves as the default activity to launch. It simply displays a layout (maybe just a big graphic), plays music for several seconds and then launches MenuActivity.
• MenuActivity - This activity is pretty straightforward. Its layout has several buttons, each corresponding to a feature of the application. The onClick() handlers for each button trigger cause the associated activity to launch.
• PlayActivity - The real application guts are implemented here. This activity needs to draw stuff onscreen, handle various types of user input, keep score and generally follow whatever game dynamics the developer wants to support.
• ScoresActivity - This activity is about as simple as SplashActivity. It does little more than load a bunch of scoring information into a TextView control within its layout.
• HelpActivity - This activity is almost identical to ScoresActivity, except that instead of displaying scores, it displays help text. Its TextView control might possibly scroll.

Each activity class should have its own corresponding layout file stored in the application resources. You could use a single layout file for ScoresActivity and HelpActivity, but it's not necessary. If you did, though, you would simply create a single layout for both and set the image in the background and the text in the TextView control at runtime, instead of within the layout file. Next: Implementing application functionality

Design for game Chippy's Revenge Version 0.0.1 for Android.

Read more ...

Signs Point To Security Improvements

Signs Point To Security Improvements

IBM is documenting up to 150 vulnerability disclosures a week. Many of them are Web application flaws. Its vulnerability database has 70,000 unique vulnerabilities and has averaged 7,700 vulnerabilities per year over the past five years. But, vulnerability disclosure figures alone don't typically tell the whole picture. There are signs that software security processes at major software vendors are maturing. Product incident response teams are addressing coding errors more quickly than ever before, and their processes are constantly being refined, IBM said in its latest X-Force Trend and Risk Report.


Overall Vulnerability Disclosures Fall
Since 2008 overall vulnerability disclosures by major enterprise software vendors has been steadily increasing, according to IBM. The trend saw a decline in 2012, when the percentage of vulnerabilities disclosed by these companies decreased by 26 percent, the company said. It's unclear if it is a one-time occurrence or if more mature, secure software development practices are contributing to the decline, according to Leslie Horacek, the IBM ISS product manager who authored the report.

Attacks Targeting Office, PDFs Retreating

IBM said a decline in exploits targeting Adobe Acrobat and Reader vulnerabilities could be attributed to the sandbox capabilities in Adobe Acrobat Reader X. Sandboxing technology makes it more difficult for cybercriminals to use Adobe software flaws to gain access to systems by preventing malicious code from accessing critical system processes. Microsoft has also been increasingly building in defensive mechanisms, making it more difficult and costly for malware writers to target document vulnerabilities. In addition to exploiting a vulnerability, a malware writer needs to write code to bypass the added defenses, IBM said.

Web Browser Flaws In Decline

The Web browser is consistently one of the paths of least resistance for attackers to gain access to a company's critical systems and files. Both Google Chrome and Mozilla Firefox added automated patching features in their browsers and have been applying security updates across their user base much faster than in years past. IBM said the overall number of Web browser vulnerabilities fell 6 percent from 2011. Even with critical browser flaws increasing nearly 60 percent in 2012, attackers find it easier to target browser components frequently plagued with Web application vulnerabilities, IBM said.

Vulnerability Remediation Nearing 100 Percent

A review of the top 10 enterprise-level software vendors found a vulnerability remediation rate of 94 percent, according to IBM. Three of the top 10 had a 100-percent remediation rate, the company said. IBM points to maturing secure development processes and product incident response teams as the sole factor in addressing vulnerabilities quickly and systematically. Now the bad news: unpatched vulnerabilities increased for the first time since 2008. A major factor to the increase could be low-severity coding errors in "small web applications, and obscure software written by individuals or tiny companies," IBM said.

Interest Rises In Software Security, Patching

Software security experts point to businesses' interest in finding ways to improve software security by getting it addressed earlier in the development cycle. A number of frameworks and models exist including the Microsoft Software Development Lifecycle, the Building Security in Maturity Model as well as the NIST software security assurance tool for developers. Better patch management also contributes to reducing the risk of a successful attack.

Read more ...