Group items tagged

If you add multiple changes to the transaction (such as another add() or remove()) and call addToBackStack(), then all changes applied before you call commit() are added to the back stack as a single transaction and the BACK key will reverse them all together.

The most significant difference in lifecycle between an activity and a fragment is how one is stored in its respective back stack. An activity is placed into a back stack of activities that's managed by the system when it's stopped, by default (so that the user can navigate back to it with the BACK key, as discussed in Tasks and Back Stack). However, a fragment is placed into a back stack managed by the host activity only when you explicitly request that the instance be saved by calling addToBackStack() during a transaction that removes the fragment.

In some cases, you might need a fragment to share events with the activity. A good way to do that is to define a callback interface inside the fragment and require that the host activity implement it. When the activity receives a callback through the interface, it can share the information with other fragments in the layout as necessary.

I haven't looked in details at the 3 other approaches but I know that a big difference between what I do in Shelves and what I've seen done in other places is how user interaction is handled. Shelves listens to scroll events on the ListView and tries to identify taps vs scrolls vs fling to always give priority to the UI. For instance, when you touch the screen to stop a fling, Shelves starts loading images, but does so only after a very short delay so that if you are touching the screen to fling some more, the fling animation won't stutter because of the extra work load. But that's details.

For completeness we really should handle the possibility of the task getting cancelled. This can happen when the user navigates away from the app and the task is killed before its completed. This will cause the onPostExecute() method to not be called and so the onRefreshComplete() method won’t be called. Depending on how the user navigates through the app, they could return to this activity without going through the complete onCreate() lifecycle, and you’ll end up with the screen still showing the “loading” progress message in the header. This is common when using tabs between multiple ListViews. Also, the documented best practices for implementing an AsyncTask says that in long running background work you should periodically check if the task has been cancelled and try to gracefully quit your work and exit. So let’s get all of that in there.

Bump™ makes sharing photos, contacts, and apps with people as simple as bumping your phones together. Compatible with Android to iPhone too!

Bump for Android is an awesome app for quickly exchanging Contact info, Pictures and even Android apps! It’s such an easy way to share information on smartphones running the Bump app. It even works between Android and iPhones, so not just Android to Android or iPhone to iPhone bumps, but a mix of any phone running the app. Many users complain that you can’t Bump music transfers but understand there are legal issues involved there, something I’m sure Bump would not knowingly want to get involved with.

5 down vote accepted One solution is to implement an OnScrollListener and make changes (like adding items, etc.) to the ListAdapter at a convenient state in its onScrollStateChanged method. The following ListActivity shows a list of integers, starting with 40, adding 10 per scroll-stop.

public class Test extends ListActivity implements OnScrollListener {    Aleph0 adapter = new Aleph0();    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setListAdapter(adapter);         getListView().setOnScrollListener(this);    }    public void onScroll(AbsListView v, int i, int j, int k) { }    public void onScrollStateChanged(AbsListView v, int state) {        if(state == OnScrollListener.SCROLL_STATE_IDLE) {                adapter.count += 10;                adapter.notifyDataSetChanged();        }    }    class Aleph0 extends BaseAdapter {        int count = 40;        public int getCount() { return count; }        public Object getItem(int pos) { return pos; }        public long getItemId(int pos) { return pos; }        public View getView(int pos, View v, ViewGroup p) {                TextView view = new TextView(Test.this);                view.setText("entry " + pos);                return view;        }    }}

You should obviously use separate threads for long running actions (like loading web-data) and might want to indicate progress in the last list item (like the market or gmail apps do).

A facility for the application to tell the system about something it wants to be doing in the background

A facility for an application to expose some of its functionality to other applications.

Worldwide, it doesn't look so bad for Apple yet; it's still the king of the hill by a long shot, steady at about 50%. Android is making inroads, though, now accounting for almost a quarter of the world's mobile web usage.

And now we get to the interesting part: the United States. The top-notch Android phones have been available in the US for longer than in other countries, and carriers there have been pushing them longer. This shows: in the US, Android has almost overtaken the iPhone OS (which excludes the iPod Touch!) in mobile web usage - 42% vs. 44%.

onSaveInstanceState() is called by Android if the Activity is being stopped and may be killed before it is resumed! This means it should store any state necessary to re-initialize to the same condition when the Activity is restarted. It is the counterpart to the onCreate() method, and in fact the savedInstanceState Bundle passed in to onCreate() is the same Bundle that you construct as outState in the onSaveInstanceState() method.

Note that saveState() must be called in both onSaveInstanceState() and onPause() to ensure that the data is saved. This is because there is no guarantee that onSaveInstanceState() will be called and because when it is called, it is called before onPause().

google最后给的判决书： Hi, After further review from our abuse team we have confirmed that your account that was closed was modifying the ad behavior which is strictly prohibited as stated in the AdSense policies. These types of violations pose a significant risk to advertisers and for this reason we can no longer work with you through any partnering AdSense account or product offering. This will be the final communication about this issue. Please do not reply to this email as you will not receive a response. Thank you for your understanding. Google AdSense 我们自始至终都不知道原因。

我Google了下 "modifying the ad behavior " 就是指你修改了 Google提供的 adsense js code 或者 sdk 唯一有可能的就是这里了 GoogleAdView adView = (GoogleAdView) activity.findViewById(R.id.ad<http://r.id.ad/> ); if (adView != null) { View vc = adView.getCurrentView(); if (vc instanceof WebView) { ((WebView) vc).destroy(); } View vn = adView.getNextView(); if (vn instanceof WebView) { ((WebView) vn).destroy(); } } 因为用了adsense之后 我们的程序老是crash 从stack trace看是因为Google adsense sdk 引起的. 资源没有释放. 然后去Adsense的那个mail list AFMA 问了 碰到2个都有同样问题的 然后有人给了个code 因为adsense sdk没有destroy ad view  所以要手动destroy下 我们就在每个有ads的activty的 onDestroy 加上这段 就好了 程序没有crash了 结果就被搞了 连负责我们android adsense sales都事先不知道 adsense team就直接把我们封了 还在beta 测试阶段的东西 还有bug  我们只是加了这个保证他资源正常释放不会影响到我们程序 结果就挂了 而且Google的态度巨NX无比 连个申述的途径都没有  只是给了个link类似事后调查

我刚刚给我的sale发了一封信： Hi Sunil, It has been long that I haven't talked to you. I have a question, when I went to the application register page, I found the page layout was changed and some of my apps were gone. For example UK TV Guide, Australia TV Guide, etc. Also, the published status are all "false". I am confused because I am still seeing my ads are clicked in the daily report. Is there anything wrong? I am nervous because I just knew that an AdSense developer's account was disabled without any warning,  and the developers themselves don't know the reason. I don't want that happened on me so I really appreciate your comment. below is the letter in AFMA group. Looking forward to your reply. Thanks. Cheers, Luke 接下来我引用了superdroid的信。看看他怎么说吧。

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.

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.

This widget allows users to input their address, and perform validation on this by talking to an address data server. The UI part is Android-specific, but there is potential to re-use the backend and have different UIs (such as GWT) that interface with it. More information will be written here soon on how to integrate this with your android project and our future plans with regards to making the widget available outside the Android environment.

Renderscript is a key new Honeycomb feature which we haven’t yet discussed in much detail

Renderscript is a new API targeted at high-performance 3D rendering and compute operations. The goal of Renderscript is to bring a lower level, higher performance API to Android developers. The target audience is the set of developers looking to maximize the performance of their applications and are comfortable working closer to the metal to achieve this

Renderscript has been used in the creation of the new visually-rich YouTube and Books apps. It is the API used in the live wallpapers shipping with the first Honeycomb tablets.

FrameLayout is designed to block out an area on the screen to display a single item. You can add multiple children to a FrameLayout, but all children are pegged to the top left of the screen. Children are drawn in a stack, with the most recently added child on top. The size of the frame layout is the size of its largest child (plus padding), visible or not (if the FrameLayout's parent permits). Views that are GONE are used for sizing only if setConsiderGoneChildrenWhenMeasuring() is set to true.

So the basic idea is: launch an AsyncTask making your service call, show a nifty progress dialog while the task thread is running, and have the task’s result be posted back to your activity once it completes. Cool, but what if the user decides to rotate the screen while your task is running? Or a phone call comes in, interrupting your app, and Android decides to kill it? Both these actions will effectively terminateyour activity, and recreate it when resuming (yes, a screen rotation kills your activity, very clever, isn’t it?). Unfortunately, any AsyncTask that was still running now holds a stale reference to your activity, because the restarted activity will be an entirely different object in memory (and it will go through onCreate(), as if the activity had started for the first time). I’m not entirely sure whether AsyncTask will actually post back the data to the old activity object (if it was a weak reference, it may already have been garbage collected), but in any case, your “new” activity will never see it, because it’s a different instance.

launches the pending intent

checkout flow finishes