Android Dev

思路转换的失败

针对的用户群体动辄就是全球目标用户，在商业判断和分析上，最基础的一个考量就是用户群体和业务模式的总量的收益是否足够大，对用户群体的研究和商业判断分析完全根据市场分析报告和数据来做判断。因此，不可避免地在程序创意思路上会沿用以前的工作思路和分析方法。 在考虑Android上的创意的同时，不自觉地就考虑和分析了如下几个方面的问题： 1. 是否为用户所必需？ 2. 技术上是否领先？ 3. 程序的粘性是否足够？ 4. 用户群体是否足够大？ 因此，沿用这个思路，不可避免地就会往大的应用和大的服务上去思考和做出判断。

经过反复地反省和对比，初步得出了这样的失败教训： 1. 对于个人开发者和小型团队来说，不适合做过于基础的程序。操作的模式和理念上的创新与用户的接受度有相当的距离。这样的事情只有大公司才有财力和可能进行推广。比如说手机生产商，他们可以通过预置的方式进行推广。而对个人开发者来说，得先证明你的想法是成功的，不能假设一个会成功的需求和应用，然后卖给设备厂商。 2. 个人开发者和小型团队不适合做大的程序，尤其是开发时间不要超过2个月。4个人，3个月的时间，对于一个小团队来说 ，是相当宝贵的。这不仅仅是时间和金钱的问题，更多的是信心问题。 3. 用户能否真正接受你的想法，是一个关键性的问题。设想和推导都很完美，唯独缺了用户是否真正喜欢和接受这一条，又没有方法进行快速地验证和试错，基本上不能成功。

Since: API Level 3

Constants for supporting speech recognition through starting an Intent

把pdialog.dismiss()改成pdialog.hide()了，我亲自试验过了的。不过Logcat里面还是有错误信息，不过不会出现FC错误

在用ProgressDialog的时候，用线程关闭的时候会出现这个错误，困扰很旧了。 详细错误信息：java.lang.IllegalArgumentException: View not attached to window manager

Their conclusion is that Android 2.1′s new speech-to-text thing works, just about, although there’s a delay of a few seconds while the phone crunches your spoken words and tries to get the gist of what you’re saying – and a few errors sneak in, particularly when dealing with those smaller words we tend to hurry over. Basically, it looks like you have an awkward choice to make – speak your messages then spend a bit of time awkwardly tidying up the few errors that will inevitably sneak in, or carry on as normal with traditional text input methods.

PackageInfo pInfo = null; try {         pInfo = getPackageManager().getPackageInfo("com.beanie.test", PackageManager.GET_META_DATA);         } catch (NameNotFoundException e) {                 e.printStackTrace(); } System.out.println(pInfo.versionCode);

Then i've tried PendingIntent.FLAG_UPDATE_CURRENT i'm no longer crashing, but it always launches the activity with extras were put in the widget that was updated the last. It looks like pending intent is shared among my widget instances

I've changed the call to  PendingIntent pending = PendingIntent.getActivity(context, appWidgetId, intent, PendingIntent.FLAG_UPDATE_CURRENT); Now everything is cool except based on discussions i'm not sure how reliable it'll be . ( Doc says it's not supported yet )

三星在移动市场的进步令人瞩目，最近的旗舰 Galaxy S (I9000) 发售短短几周就已经达到了百万销量，三星期望该机型的总销量能够达到一千万部。考虑到这东西售价 600 美元，而且只在有限的国家有售，系统还不是最新，你应该知道乔教主为什么会在新闻发布会上提起韩国公司了吧

三星的机海战术在近几年获得了巨大的成功，WM，Android，自身的非智能机系统，Bada 几条腿走路，机型的定位明确，做工质量稳定，以此换来了市场份额的不断攀升，三星给其他厂商带来了很大的压力，不过对于我们消费者来说，竞争是越激烈越好啊

When you switch orientations, Android will create a new View. You're probably getting crashes because your background thread is trying to change the state on the old one. (It may also be having trouble because your background thread isn't on the UI thread) I'd suggest making that mHandler volatile and updating it when the orientation changes.

An AppWidgetProvider is a BroadcastReceiver. That gives you two possibilities right off the bat: 1. Have it also handle whatever other Intents you were planning on setting up with a separate BroadcastReceiver, or 2. Send an Intent from whatever component you want to the AppWidgetProvider. In other words, don't worry about trying to talk directly to the app widget (which I suspect is impossible) -- just talk to your code that already talks to the app widget.

I update my widget from within my app, when I delete/add entries to a list. To do this, I have a method (updateWidget) and a static String (UPDATE_ACTION). My updateWidget() method sends a broadcast which is received by the widget class and then calls onUpdate() with the appropriate params: private void updateWidget() {                 Intent i = new Intent(this, TVWidget.class);                 i.setAction(TVWidget.UPDATE_ACTION);                 sendBroadcast(i);         } In TVWidget class: @Override         public void onReceive(Context context, Intent intent) {                 String action = intent.getAction();                 if (action != null && action.equals(UPDATE_ACTION)) {                         final AppWidgetManager manager = AppWidgetManager.getInstance (context);                         onUpdate(context, manager,                                         manager.getAppWidgetIds(new ComponentName(                                                         context, TVWidget.class)                                         )                         );                 }                 else {                         super.onReceive(context, intent);                 }         } This seems to work fine.

Mark Murphy is the founder of CommonsWare and is the author of _The Busy Coder's Guide to Android Development_, _The Busy Coder's Guide to *Advanced* Android Development_, and _Android Programming Tutorials_.

RemoteViews can't manipulate a buttons enabled/disabled state, but it can modify its visibility. So the trick is to have two buttons, the real one, and an other which is designed to look like the real one in disabled state, and change witch one is visible.

<Button android:id="@+id/startbutton" android:text="Start" android:visibility="visible"></Button> <Button android:id="@+id/startbutton_disabled" android:text="Start" android:clickable="false" android:textColor="#999999" android:visibility="gone"></Button>   <Button android:id="@+id/stopbutton" android:text="Stop"  android:visibility="gone"></Button> <Button android:id="@+id/stopbutton_disabled" android:text="Stop" android:clickable="false" android:textColor="#999999" android:visibility="visible"></Button>

RemoteViews remoteView = new RemoteViews(context.getPackageName(), R.layout.widget); remoteView.setViewVisibility(R.id.startbutton, View.GONE); remoteView.setViewVisibility(R.id.startbutton_disabled, View.VISIBLE); remoteView.setViewVisibility(R.id.stopbutton, View.VISIBLE); remoteView.setViewVisibility(R.id.stopbutton_disabled, View.GONE); AppWidgetManager.getInstance(context).updateAppWidget(appWidgetId, remoteView);