## Android Application Design and Development Principles for Seamless Experience ###
For any application,there are some if's and but's.i mean to say you should have to follow some coding and design guidelines for the seamless experience.
Specially, for developers.You should take care few points which i am going to discuss below:
1) Do not try to inflict the whole application in any sort of MVC,MVP,MVVM .etc patterns.there are two things can happen.one is, it can make your application in good shape or even worse that you will have to re-write your whole application which is very impossible kind of effort, specially in service based companies.my whole intent is the project complexity in terms of performance,UI Experience,Code Readability,Flexibility and specially OOP's concept implementation. So,i mean to say you should not inflict instead you try your own but make it more OOPS wise intact then maintain some general code standard of Java.that's it.i can give you assurance that it will be more reliable and maintainable code.now lets discuss about Android Application Development perspective:
2) Even if your application is fast and responsive there are few points design decisions can still cause problems for users:
a)Unplanned Interaction with the other applications or dialogs
b)carelessness about data
c)Unintended Blocking
To avoid these problems,it helps to understand the context in which your applications run and the system interactions that can affect your application.In short, you should strive to develop an application that interacts seamlessly with the system and with other applications.you
3) Let me tell you a very common problem in android is when an application's background process.a service or broadcast receiver — pops up a dialog in response to some event. This may seem like harmless behavior, especially when you are building and testing your application in isolation, on the emulator. However, when your application is run on an actual device, your application may not have user focus at the time your background process displays the dialog. So it could end up that your application would display it's dialog behind the active application, or it could take focus from the current application and display the dialog in front of whatever the user was doing (such as dialing a phone call, for example). That behavior would not work for your application or for the user.
To avoid these problems, your application should use the proper system facility for notifying the user — the Notification classes. Using notifications, your application can signal the user that an event has taken place, by displaying an icon in the status bar rather than taking focus and interrupting the user.
4)Let me again come up with another seamlessness problem is when an activity inadvertently loses state or user data because it doesn't correctly implement the onPause() and other lifecycle methods. Or, if your application exposes data intended to be used by other applications, you should expose it via a ContentProvider, rather than (for example) doing so through a world-readable raw file or database.
What those examples have in common is that they involve cooperating nicely with the system and other applications. The Android system is designed to treat applications as a sort of federation of loosely-coupled components, rather than chunks of black-box code. This allows you as the developer to view the entire system as just an even-larger federation of these components. This benefits you by allowing you to integrate cleanly and seamlessly with other applications, and so you should design your own code to return the favor.
5)Don't Drop Data: It is very obvious to say that and it's important to remember that another Activity can pop up over your own Activity at any moment. This will fire the onSaveInstanceState() and onPause() methods, then at any point your application can be killed.
If the user was editing data in your application when the other Activity appeared, your application will likely lose that data when your application is killed.
Unless,you save the work in progress first. The "Android Way" is to do just that: Android applications that accept or edit input should override the onSaveInstanceState() method and save their state in some appropriate fashion. When the user revisits the application, she should be able to retrieve her data.
A classic example of a good use of this behavior is a mail application. If the user was composing an email when another Activity started up, the application should save the in-process email as a draft.Always keep in mind that Android is a mobile platform.
6)Don't Expose Raw Data:
Exposing raw data requires other applications to understand your data format; if you change that format, you'll break any other applications that aren't similarly updated.
The "Android Way" is to create a ContentProvider to expose your data to other applications via a clean, well-thought-out, and maintainable API. Using a ContentProvider is much like inserting a Java language interface to split up and componentize two tightly-coupled pieces of code. This means you'll be able to modify the internal format of your data without changing the interface exposed by the ContentProvider, and this without affecting other applications .
7)Don't Interrupt the User:If the user is running an application (such as the Phone application during a call) it's a pretty safe bet he did it on purpose. That's why you should avoid spawning activities except in direct response to user input from the current Activity.I mean to say that .That is, don't call startActivity() from BroadcastReceivers or Services running in the background. if you do that then whatever application is currently running, and result in an annoyed user. Perhaps even worse, your Activity may become a "keystroke bandit" and receive some of the input the user was in the middle of providing to the previous Activity. Depending on what your application does, this could be application crash or bad news for you.Instead of spawning Activity UIs directly from the background, you should instead use the NotificationManager to set Notifications. These will appear in the status bar, and the user can then click on them at his leisure, to see what your application has to show him.
8)Got a Lot to Do? Do it in a Thread:
If your application needs to perform some expensive or long-running computation, you should probably move it to a thread. This will prevent the dreaded "Application Not Responding" dialog from being displayed to the user, with the ultimate result being the fiery demise of your application.
By default, all code in an Activity as well as all its Views run in the same thread. This is the same thread that also handles UI events. For example, when the user presses a key, a key-down event is added to the Activity's main thread's queue. The event handler system needs to dequeue and handle that event quickly; if it doesn't, the system concludes after a few seconds that the application is hung and offers to kill it for the user.
If you have long-running code, running it inline in your Activity will run it on the event handler thread, effectively blocking the event handler. This will delay input processing, and result in the ANR dialogs. To avoid this, move your computations to a thread.
Now i am goig to discuss the very importpart of the Application and i have seen 90% people does this mistake whiole android application development.
9)Don't Overload a Single Activity Screen:
Any application worth using will probably have several different screens. When designing the screens of your UI, be sure to make use of multiple Activity object instances.
Depending on your development background, you may interpret an Activity as similar to something like a Java Applet, in that it is the entry point for your application. However, that's not quite accurate: where an Applet subclass is the single entry point for a Java Applet, an Activity should be thought of as one of potentially several entry points to your application. The only difference between your "main" Activity and any others you might have is that the "main" one just happens to be the only one that expressed an interest in the "android.intent.action.MAIN" action in your AndroidManifest..xml file.
So, when designing your application, think of your application as a federation of Activity objects. This will make your code a lot more maintainable in the long run, and as a nice side effect also plays nicely with Android's application history and "backstack" model.
10) Assume the Network is Slow: Android devices will come with a variety of network-connectivity options. All will have some data-access provision, though some will be faster than others. The lowest common denominator, however, is GPRS, the non-3G data service for GSM networks. Even 3G-capable devices will spend lots of time on non-3G networks, so slow networks will remain a reality for quite a long time to come.
That's why you should always code your applications to minimize network accesses and bandwidth. You can't assume the network is fast, so you should always plan for it to be slow. If your users happen to be on faster networks, then that's great — their experience will only improve. You want to avoid the inverse case though: applications that are usable some of the time, but frustratingly slow the rest based on where the user is at any given moment are likely to be unpopular.
One potential gotcha here is that it's very easy to fall into this trap if you're using the emulator, since the emulator uses your desktop computer's network connection. That's almost guaranteed to be much faster than a cell network, so you'll want to change the settings on the emulator that simulate slower network speeds. You can do this in Android Studio via the AVD Manager or via a command-line option when starting the emulator.
11) Do Conserve the Device Battery:Two of the biggest consumers of battery power are the processor, and the radio; that's why it's important to write your applications to do as little work as possible, and use the network as infrequently as possible.
Minimizing the amount of processor time your application uses really comes down to writing efficient code. To minimize the power drain from using the radio, be sure to handle error conditions gracefully, and only fetch what you need. For example, don't constantly retry a network operation if one failed. If it failed once, it's likely because the user has no reception, so it's probably going to fail again if you try right away; all you'll do is waste battery power.
Users are pretty smart: if your program is power-hungry, you can count on them noticing. The only thing you can be sure of at that point is that your program won't stay installed very long.
So atlast i would like to conclude here that is if any developer follows thease simple steps for his application development then i can bet his or her application
would be not just seamless rather it would be fast,reliable,more battery conserve and will work great in the slow ans fast network.All together it will be
great experience.
For any application,there are some if's and but's.i mean to say you should have to follow some coding and design guidelines for the seamless experience.
Specially, for developers.You should take care few points which i am going to discuss below:
1) Do not try to inflict the whole application in any sort of MVC,MVP,MVVM .etc patterns.there are two things can happen.one is, it can make your application in good shape or even worse that you will have to re-write your whole application which is very impossible kind of effort, specially in service based companies.my whole intent is the project complexity in terms of performance,UI Experience,Code Readability,Flexibility and specially OOP's concept implementation. So,i mean to say you should not inflict instead you try your own but make it more OOPS wise intact then maintain some general code standard of Java.that's it.i can give you assurance that it will be more reliable and maintainable code.now lets discuss about Android Application Development perspective:
2) Even if your application is fast and responsive there are few points design decisions can still cause problems for users:
a)Unplanned Interaction with the other applications or dialogs
b)carelessness about data
c)Unintended Blocking
To avoid these problems,it helps to understand the context in which your applications run and the system interactions that can affect your application.In short, you should strive to develop an application that interacts seamlessly with the system and with other applications.you
3) Let me tell you a very common problem in android is when an application's background process.a service or broadcast receiver — pops up a dialog in response to some event. This may seem like harmless behavior, especially when you are building and testing your application in isolation, on the emulator. However, when your application is run on an actual device, your application may not have user focus at the time your background process displays the dialog. So it could end up that your application would display it's dialog behind the active application, or it could take focus from the current application and display the dialog in front of whatever the user was doing (such as dialing a phone call, for example). That behavior would not work for your application or for the user.
To avoid these problems, your application should use the proper system facility for notifying the user — the Notification classes. Using notifications, your application can signal the user that an event has taken place, by displaying an icon in the status bar rather than taking focus and interrupting the user.
4)Let me again come up with another seamlessness problem is when an activity inadvertently loses state or user data because it doesn't correctly implement the onPause() and other lifecycle methods. Or, if your application exposes data intended to be used by other applications, you should expose it via a ContentProvider, rather than (for example) doing so through a world-readable raw file or database.
What those examples have in common is that they involve cooperating nicely with the system and other applications. The Android system is designed to treat applications as a sort of federation of loosely-coupled components, rather than chunks of black-box code. This allows you as the developer to view the entire system as just an even-larger federation of these components. This benefits you by allowing you to integrate cleanly and seamlessly with other applications, and so you should design your own code to return the favor.
5)Don't Drop Data: It is very obvious to say that and it's important to remember that another Activity can pop up over your own Activity at any moment. This will fire the onSaveInstanceState() and onPause() methods, then at any point your application can be killed.
If the user was editing data in your application when the other Activity appeared, your application will likely lose that data when your application is killed.
Unless,you save the work in progress first. The "Android Way" is to do just that: Android applications that accept or edit input should override the onSaveInstanceState() method and save their state in some appropriate fashion. When the user revisits the application, she should be able to retrieve her data.
A classic example of a good use of this behavior is a mail application. If the user was composing an email when another Activity started up, the application should save the in-process email as a draft.Always keep in mind that Android is a mobile platform.
6)Don't Expose Raw Data:
Exposing raw data requires other applications to understand your data format; if you change that format, you'll break any other applications that aren't similarly updated.
The "Android Way" is to create a ContentProvider to expose your data to other applications via a clean, well-thought-out, and maintainable API. Using a ContentProvider is much like inserting a Java language interface to split up and componentize two tightly-coupled pieces of code. This means you'll be able to modify the internal format of your data without changing the interface exposed by the ContentProvider, and this without affecting other applications .
7)Don't Interrupt the User:If the user is running an application (such as the Phone application during a call) it's a pretty safe bet he did it on purpose. That's why you should avoid spawning activities except in direct response to user input from the current Activity.I mean to say that .That is, don't call startActivity() from BroadcastReceivers or Services running in the background. if you do that then whatever application is currently running, and result in an annoyed user. Perhaps even worse, your Activity may become a "keystroke bandit" and receive some of the input the user was in the middle of providing to the previous Activity. Depending on what your application does, this could be application crash or bad news for you.Instead of spawning Activity UIs directly from the background, you should instead use the NotificationManager to set Notifications. These will appear in the status bar, and the user can then click on them at his leisure, to see what your application has to show him.
8)Got a Lot to Do? Do it in a Thread:
If your application needs to perform some expensive or long-running computation, you should probably move it to a thread. This will prevent the dreaded "Application Not Responding" dialog from being displayed to the user, with the ultimate result being the fiery demise of your application.
By default, all code in an Activity as well as all its Views run in the same thread. This is the same thread that also handles UI events. For example, when the user presses a key, a key-down event is added to the Activity's main thread's queue. The event handler system needs to dequeue and handle that event quickly; if it doesn't, the system concludes after a few seconds that the application is hung and offers to kill it for the user.
If you have long-running code, running it inline in your Activity will run it on the event handler thread, effectively blocking the event handler. This will delay input processing, and result in the ANR dialogs. To avoid this, move your computations to a thread.
Now i am goig to discuss the very importpart of the Application and i have seen 90% people does this mistake whiole android application development.
9)Don't Overload a Single Activity Screen:
Any application worth using will probably have several different screens. When designing the screens of your UI, be sure to make use of multiple Activity object instances.
Depending on your development background, you may interpret an Activity as similar to something like a Java Applet, in that it is the entry point for your application. However, that's not quite accurate: where an Applet subclass is the single entry point for a Java Applet, an Activity should be thought of as one of potentially several entry points to your application. The only difference between your "main" Activity and any others you might have is that the "main" one just happens to be the only one that expressed an interest in the "android.intent.action.MAIN" action in your AndroidManifest..xml file.
So, when designing your application, think of your application as a federation of Activity objects. This will make your code a lot more maintainable in the long run, and as a nice side effect also plays nicely with Android's application history and "backstack" model.
10) Assume the Network is Slow: Android devices will come with a variety of network-connectivity options. All will have some data-access provision, though some will be faster than others. The lowest common denominator, however, is GPRS, the non-3G data service for GSM networks. Even 3G-capable devices will spend lots of time on non-3G networks, so slow networks will remain a reality for quite a long time to come.
That's why you should always code your applications to minimize network accesses and bandwidth. You can't assume the network is fast, so you should always plan for it to be slow. If your users happen to be on faster networks, then that's great — their experience will only improve. You want to avoid the inverse case though: applications that are usable some of the time, but frustratingly slow the rest based on where the user is at any given moment are likely to be unpopular.
One potential gotcha here is that it's very easy to fall into this trap if you're using the emulator, since the emulator uses your desktop computer's network connection. That's almost guaranteed to be much faster than a cell network, so you'll want to change the settings on the emulator that simulate slower network speeds. You can do this in Android Studio via the AVD Manager or via a command-line option when starting the emulator.
11) Do Conserve the Device Battery:Two of the biggest consumers of battery power are the processor, and the radio; that's why it's important to write your applications to do as little work as possible, and use the network as infrequently as possible.
Minimizing the amount of processor time your application uses really comes down to writing efficient code. To minimize the power drain from using the radio, be sure to handle error conditions gracefully, and only fetch what you need. For example, don't constantly retry a network operation if one failed. If it failed once, it's likely because the user has no reception, so it's probably going to fail again if you try right away; all you'll do is waste battery power.
Users are pretty smart: if your program is power-hungry, you can count on them noticing. The only thing you can be sure of at that point is that your program won't stay installed very long.
So atlast i would like to conclude here that is if any developer follows thease simple steps for his application development then i can bet his or her application
would be not just seamless rather it would be fast,reliable,more battery conserve and will work great in the slow ans fast network.All together it will be
great experience.
No comments:
Post a Comment