Group items tagged

This is androidpatterns.com, a set of interaction patterns that can help you design Android apps. An interaction pattern is a short hand summary of a design solution that has proven to work more than once. Please be inspired: use them as a guide, not as a law.

Additionally, you can feel free to use the Search bar selection mechanism as a replacement for tabs since it’s really just a fast pivot on a data set. If you have more than 3 data sets, tabs become problematic since no more than 3 can be onscreen at once. For example, look at how we implemented the Profile switching mechanism below:

The good news for developers is you get this highly functional contacts feature for free if users choose to sync contact information into your app

The good news for developers is you get this highly functional contacts feature for free if users choose to sync contact information into your app. QuickContact for Android provides instant access to a contact's information and communication modes.

This projects aims to provide a reusable action bar widget. The action bar replaces the default title and is therefor located at the top of the screen. The action bar highlights important actions. The action bar pattern is well documented over at Android Patterns. The action bar widget is an Library Project. This means that there's no need to copy-paste resources into your own project, simply add the action bar widget as a reference to your existing project.

The action bar: is located at the top of the screen to support navigation and highlight important functionalities replaces the title bar (which is often included into it) is best used for actions across your app, like search, refresh and compose can provide a quick link to app homeby tapping the app logo is preferably not contextual, but actions can differ from page to page

Use when You want to bring key actions on screen, so they are in sight. You don't want to hide them under the menu-button. The action bar is best used for common actions like search, refresh and compose. When screen real estate is valuable, consider putting actions in the options menu.

I’ve run into the following generalized question a lot recently: I have an event that occurs in the background. I want to update my activity, if the activity is on the screen. Otherwise, I want to raise a Notification.

Hence, the recipe for the activity-or-Notification pattern is: Define an action string you will use when the event occurs that you want to go to the activity or notification (e.g., com.commonsware.java.packages.are.fun.EVENT). Dynamically register a BroadcastReceiever in your activity, with an IntentFilter set up for the aforementioned action string and with a positive priority (the default priority for a filter is 0). This receiver should then have the activity do whatever it needs to do to update the UI based on this event. The receiver should also call abortBroadcast() to prevent others from getting it. Be sure to register the receiver in onStart() or onResume() and unregister the receiver in the corresponding onStop or onPause() method. Register in your manifest a BroadcastReceiver, with an <intent-filter> set up for the aforementioned action string. This receiver should raise the Notification. In your service (e.g., an IntentService), when the event occurs, call sendOrderedBroadcast(). And that’s it. If the activity is on-screen, its receiver will be registered, so it will get the event, process it, and cancel the broadcast. If the activity is not on-screen, its receiver will not be registered, so the event will go to the default handler, in the form of your manifest-registered BroadcastReceiver, which will raise the Notification.

Apple tends to do that a lot. It’s deeply ingrained in their culture, priorities, and product development practices. In brief, their philosophy seems to be to ship only what’s great and leave out the rest. That’s why, instead of having a bad copy-and-paste implementation for the iPhone’s first two years, we just didn’t have one at all

Android as a platform, both in hardware and software, doesn’t reflect this. Nearly every hardware and software release has major shortcomings or rough edges. Many details and design decisions are lacking, wrong, or inexplicable. Neither Google nor the current Android device manufacturers embody the part of Apple’s culture that allows them to release a great product on day one. They have a different pattern: It’s always getting better. We’re always supposedly one or two releases from it being really great.

I never make technology-buying decisions based on future promises, rumors, or potential. I let other people be the bleeding-edge extremely early adopters, and I stick with what I know will work and stay out of my way. I don’t buy things that are “getting better”, because they usually don’t. Whatever caused them to be lacking in their current release will usually prevent them from being great in future releases. I buy things that are great today. They’re usually things that have been great since day one. And, more often than not, they’re Apple products.

The concept of ActionBar has been introduced with the Twitter application for Android. More recently, we have seen this widget in the Google I/O 2010 schedule application. To sum up, an ActionBar can be considered as an advanced title bar that is capable of: containing several ActionBaritems (similar to buttons) being styled so that the general look’n'feel of the application is in accordance with the underlying brand/visual identity containing a title to show the user a summary of the screen content featuring several user interaction pattern.

如果你呼叫 startService() 多次，每一次的呼叫都會被轉成一個 message，並放在 mServiceLooper 的 message queue 中，等待被服務。一個 message 所對應的工作被完成後，才會繼續服務下一個工作。所以，這些等待被服務的工作，並不是一起並行 (Concurrent) 的，而是循序執行。

從研究這個 IntentService 的原始碼，我們可以學到如何運用簡單的 pattern (Service + Handler + HandlerThread)，幫我們更簡易與有系統地，完成我們所想要做的事

最後我們先前說過，在 IntentServcie 中等待被服務的工作，並不會被一起並行，而是循序執行。如果你今天想要這些等待被服務的工作，能夠一起被並行，在研讀完這個 IntentService 的原始碼後，你自己知不知道如何寫個可支援並行工作的 IntentService？ 提示：可以用 Service + AsyncTask 的組合