Re: [android-developers] Tabs as IPhone
It is definitely possible to have Tabs and and stack fragments with FragmentManager. However, when using the support library, it is buggy on 3.0 devices. (see https://code.google.com/p/android/issues/detail?id=34775). And using FragmentManager to programatically show/hide Fragments is clumsy since it calls their onStart methods. I'm really not happy with Android provided ways to do this, though it should be possible to make something similar if you have a lot of time. Maybe using a TabHost will be better for you. Unfortunately the I can't find examples easily, since the Android team has chosen to redirect them. Vedran Rodic On Wed, Aug 29, 2012 at 8:54 AM, chinh quach quachtoanch...@gmail.comwrote: Dear all, I want to make a application which will use Tabs. These Tabs will have behaviour as IPhone that means : Tab 1: A - B Tab 2: C - D But when from A to B, we will still have Tabs at the bottom of screen. The B screen will replace the A screen but doesn't replace all screen. Please help me, how to do it. Thanks in advance, -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Android support library v4 problems with soft keyboard on 3.0 devices.
Hi, I'm using the latest version of Android Support Library (for Fragment, FragmentActivity etc classes). This bug is present on 3.0 devices (tested with 2.1 emulator from Android SDK), but not on 4.0.3 (Samsung Galaxy S2). I have a case where I'm implementing Tab content with Fragments, where one Fragment (test1) is replaced by another (test2). If the test1 fragment contains an EditText widget, keyboard shows up when the EditText is focused. However, when I replace the test1 Fragment with test2 Fragment (with Button click or other event in test1 fragment) like this: FragmentManager fragmentManager = getActivity().getSupportFragmentManager(); FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction(); Fragment fragment1 = getActivity().getSupportFragmentManager().findFragmentByTag(simple); fragmentTransaction.detach(fragment1); fragmentTransaction.add(R.id.realtabcontent, fragment); //fragmentTransaction.replace(R.id.realtabcontent, fragment); // using just .replace also fails in the same way fragmentTransaction.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE); fragmentTransaction.addToBackStack(null); fragmentTransaction.commit(); and then go back to the test1 activity, I can no longer get the keyboard to show up when focusing the EditText widget. At the end of the mail there's a link to a minimal project that reproduces this problem (I've included the support library). Steps to reproduce: 1. Touch in EditText1 so that the keyboard appears. 2. Touch done after entering text (so the keyboard closes). 3. Click on Button to show test2 fragment 4. Press back to go back to test1 fragment 5. try touching EditText1 to make the keyboard show again (doesn't show) So this works as expected when the App is run on Android 4.0.3 https://github.com/vrodic/androdidtests/zipball/master I've also submitted this as a bug report here: https://code.google.com/p/android/issues/detail?id=34775 Thanks, Vedran Rodic -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Dialer consuming data
Hi I've seen in About Phone - Battery - Battery use - Dialer that it has been sending/receiving data at maybe 20 kb an hour. What's funny is that it does that even when it's positively not connected to any network (GSM/3G data is disabled, wireless access is not available). Could it be that this is actually referring to the bytes used for talking to the GSM part of the phone through a serial interface/RIL? I'm using LeeDroid_HD 3.3.3 R5 (Gingerbread 2.3.3) but I don't think it's LeeDroid specific. Thanks, Vedran Rodic -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Dialer consuming data
Thanks! I thought this kind of general knowledge would be useful for developers to have too. Vedran On Thu, Aug 18, 2011 at 10:33 AM, Appaholics raghavs...@appaholics.in wrote: Your question is also not SDK specific. Try android-discuss. Thanks On Thu, Aug 18, 2011 at 1:03 PM, Vedran Rodic vro...@gmail.com wrote: Hi I've seen in About Phone - Battery - Battery use - Dialer that it has been sending/receiving data at maybe 20 kb an hour. What's funny is that it does that even when it's positively not connected to any network (GSM/3G data is disabled, wireless access is not available). Could it be that this is actually referring to the bytes used for talking to the GSM part of the phone through a serial interface/RIL? I'm using LeeDroid_HD 3.3.3 R5 (Gingerbread 2.3.3) but I don't think it's LeeDroid specific. Thanks, Vedran Rodic -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Raghav Sood CEO/Founder/Owner/Dictator/Tyrant at Appaholics (Basically all titles required to have complete control) http://www.raghavsood.com/ https://market.android.com/developer?pub=Appaholics http://www.appaholics.in/ -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Thin Java over C++ App
I'd say, Go and look at kwaak3 code http://code.google.com/p/kwaak3/ While it uses OpenGL ES for graphics, the sound and input portions at least should be useful to you. On Thu, Aug 26, 2010 at 7:25 AM, Lukas Adamec luk.ada...@gmail.com wrote: Hi, I think NDK could solve your problem. I studied some problems about passing bitmap between Java and C++. Take a look at jnigraphics library in NDK (it's new in android-8 API) or useful is also direct ByteBuffer (for older Android versions). On 25 srp, 20:18, Maomor maldw...@gmail.com wrote: In order to easily and quickly port a C++ app to Android, can one just write a thin Java layer that gets the screen contents from C++ and blits it to the display; and sends mouse clicks to a C++ handler ? Or would this not work for some reason ? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Android Emulator vs iPhone emulator (Why does it take so long)
On Thu, Aug 26, 2010 at 7:37 PM, Dianne Hackborn hack...@android.com wrote: Of the things in the world to worry about, this is probably pretty low on the list. :) (We have devices that we reflash with entire system images many times a day, and it has never crossed my mind to worry about that.) Okay, thanks for the re-assurance. (Though I'd still like the workflow without the device to be faster :-) Thanks again! Vedran -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Android Emulator vs iPhone emulator (Why does it take so long)
On Tue, Aug 24, 2010 at 11:41 PM, Dianne Hackborn hack...@android.com wrote: On Tue, Aug 24, 2010 at 1:12 PM, Vedran Rodic vro...@gmail.com wrote: Both things contribute to iPhone development being significantly faster. I wish google did something like this for Android 3.0. I don't think the significant effort to get a production quality Android simulator, that ends up only being able to run on Linux, would be anywhere near worth the effort. Yeah, I understand the complexities of making this work. That's why iPhone development is reasonable only on Mac OS X. And that's one of the reasons why iPhone development feels more comfortable. I really feel that any step in making android development more comfortable is worth it. Windows Mobile 7 is coming, and while it may sound like a joke right now, it's not all that impossible that MS will make a giant push for the adoption of that platform. Maybe a reasonable compromise would be to make the emulator actually use x86 code, that can be virtualized more efficiently (see VirtualBox/VMWare/etc, and I think that even qemu does x86-x86 faster than it does arm-x86. Also, as has been pointed out, you should only need to boot the emulator once. After that you keep it running and just reinstall your app on it... just like working with a device. Hmm, this is not the only reason for having a lighter testing environment. Testing android apps gets slower as the .apk files get bigger, so figuring out on how to efficiently transfer and apply development deltas (maybe by supporting deployment/running of projects with multiple .class files instead of .dex) could also speed up the code/test cycle. I'm not sure if this is even feasible, given that I don't know the details of Davlik VM and the runtime. Maybe just skipping pack/unpack process for .apk would provide great speed improvements. Again, if you figured out any way to make the code/test workflow faster (improvements in Eclipse Plugin very much appreciated also), people will be eternally grateful, I'm sure of it. Thanks for replying, you're making a great platform here! Vedran -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Android Emulator vs iPhone emulator (Why does it take so long)
On Wed, Aug 25, 2010 at 5:39 PM, Frank Weiss fewe...@gmail.com wrote: Just to be a bit cheeky, why use the Android emulator at all? You know it doesn't cost $99/year to to run your Android apps on a device. I'm worried about flash memory in my phone wearing down, + I mostly find it more convenient to have results on the same screen, on a device I don't have to hold in my hands. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Android Emulator vs iPhone emulator (Why does it take so long)
AFAIK, iPhone SDK includes a simulator not an emulator, which means it uses native x86 code and not an ARM emulator. Additionally, iPhone simulator probably doesn't need to start the vritualized kernel, but uses hosts kernel features to create a sandbox for testing iPhone apps. Both things contribute to iPhone development being significantly faster. I wish google did something like this for Android 3.0. Vedran On Tue, Aug 24, 2010 at 10:00 PM, Sari sarihi...@gmail.com wrote: I have a fairly fast machine, and I boot into Windows 7 or Mac OS depending on which work I need to do. When I start the Android emulator it takes around 2-3 minutes and its sluggish when its ready. However, the iPhone emulator in Mac OS takes around 10 seconds at most and its very smooth when its ready. Why is that? Is it something we will continue to see in the future or will this be resolved in the future? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Making Android development more enjoyable
Hello all I'm sorry if some of these things have been mentioned before, but I just joined this list today. Here's some things Google should look into: 0. Include android market in the emulator/test environment That should be fast and easy to do. 1. Try finding some ways to speed up the compile/test cycle: a) Avoid moving too much stuff arround Currently every time an .apk file must be produced (compressed) on the developers machine, containing all the code and application resources. This apk that contains everything is then transferred to the phone or emu. It's then unpacked on the phone and the install procedure is run. It doesn't matter if you just changed one class file, the whole thing is moved around. I understand that permissions are managed during the install process, but this could be solved in some other way like trusting the code for that app by default. b) Make the test environment run in native code during the development process I know that using an emulator was a nice and fast solution for you, but a lot of time and energy is lost on emulating ARM. Davlik runs on x86, and all other code also. Why don't we just make a jailed/chrooted native environment for testing available? I know that this is not a straightforward thing to implement on Windows, and there might be difficulties making this run on Mac OSX, but it's really worth it. 2. Improve the visual layout editor. There's so many ways this could be improved, but making it faster/more intuitive is the general idea. One quick suggestion: Try making it easier to jump to respective code implementations or have an option to generate event handlers etc. code if no code referencing that UI object is found. Example of a great code editor/UI designer integration is Borland Delphi. Even really old versions have ease of use that Android developers could only dream of. Android API is more abstract and UIs have relative layouts, but most of the great concepts from Delphi still apply. Item 1 b) could also create possibilities for the UI designer tool. There's a blog post with the content of this mail at http://vrodic.blogspot.com/2010/07/making-android-development-more.html� -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: App Inventor
Hi all, I'm surprised nobody talked about that new google lab product : http://appinventor.googlelabs.com/about/ It's seems a lot more polished and easy to use than the eclipse plugin. I guess people will comment more when it's available to the general public, but yeah, it sounds great. Good job Android developers! Vedran -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Making Android development more enjoyable
Hello all I'm sorry if some of these things have been mentioned before, but I just joined this list today. Here's some things Google should look into: 0. Include android market in the emulator/test environment That should be fast and easy to do. 1. Try finding some ways to speed up the compile/test cycle: a) Avoid moving too much stuff arround Currently every time an .apk file must be produced (compressed) on the developers machine, containing all the code and application resources. This apk that contains everything is then transferred to the phone or emu. It's then unpacked on the phone and the install procedure is run. It doesn't matter if you just changed one class file, the whole thing is moved around. I understand that permissions are managed during the install process, but this could be solved in some other way like trusting the code for that app by default. b) Make the test environment run in native code during the development process I know that using an emulator was a nice and fast solution for you, but a lot of time and energy is lost on emulating ARM. Davlik runs on x86, and all other code also. Why don't we just make a jailed/chrooted native environment for testing available? I know that this is not a straightforward thing to implement on Windows, and there might be difficulties making this run on Mac OSX, but it's really worth it. 2. Improve the visual layout editor. There's so many ways this could be improved, but making it faster/more intuitive is the general idea. One quick suggestion: Try making it easier to jump to respective code implementations or have an option to generate event handlers etc. code if no code referencing that UI object is found. Example of a great code editor/UI designer integration is Borland Delphi. Even really old versions have ease of use that Android developers could only dream of. Android API is more abstract and UIs have relative layouts, but most of the great concepts from Delphi still apply. Item 1 b) could also create possibilities for the UI designer tool. There's a blog post with the content of this mail at http://vrodic.blogspot.com/2010/07/making-android-development-more.html -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Are Android apps developed with the NDK slower than their counterparts on other OS's?
Hi Simon, (I've put you in CC because for some reason my mails to android-developers are still not getting through.) I've also asked myself the same question. The thing is that Android API probably doesn't expose low level APIs for doing hardware accelerated surface scaling and color space ( YUV- RGB ) conversion. These are two basic conditions for building efficient video decoders since they offload the CPU from doing stupid work where every byte of every frame must be processed individually by the CPU. This hardware is present in most 2D accelerators in mainstream hardware for at least 10 years now, so it should be in every android device also. This is probably the main reason for high CPU usage, since it destorys both the CPU cache and uses resources. Other than scaling and color, other things can be accelerated by using DSP hardware that could be different on different android devices. Also using VFP/NEON instructions can help, but for scaling and colorspace conversion, it's best to offload it to dedicated hardware. It is possible that hw scaling and colorspace conversion could work with OpenGL ES, but not all devices support that. I guess that even the devices without OpenGL ES hw acceleration still have sufficient 2D and video acceleration to support this. NDK r3 and r4 added some OpenGL ES and VFP/NEON support. It's unclear from the ChangeLog if this can be used on Android 2.2 only or if it works on older Androids. You can try your look by looking at Android platform source code and finding where is low level video implemented for the standard media player. And lets hope somebody from google has a better answer :) Vedran On Tue, Jul 6, 2010 at 11:25 AM, Simon Broenner simonbroen...@gmail.comwrote: Hello developers! I've been wondering lately, about the sad situation of media playback on Android - namely: Video that isn't supported in hardware and/ or natively supported by Android OS. Coming from Windows Mobile devices, I was suprised (and frankly, dismayed) to see that things like simple playback of an XviD-encoded AVI file were not possible, even with third party apps. Currently there is only one application available (RockPlayer, currently in beta), and it only runs well on high-end devices, due to the need for immense CPU power. The same videos that stutter using this only usable DivX/XviD player on Android (I need to overclock my Milestone's Cortex A8 to get it smooth) run perfectly well on older Windows Mobile devices such as the Touch Diamond/Touch Pro/Touch Pro 2 - all of which use far slower CPUs. Android devices with the same CPUs can't even run RockPlayer because it uses CPU features that aren't even available on these older Qualcomm chips - probably needed because otherwise the performance wouldn't be up to par, even on a Cortex A8 or Snapdragon... So what exactly is the problem with Android? Why is it so difficult to develop efficient decoders for video formats that aren't natively supported? Are codecs usually written in a way that makes them impossible to implement with the tools available for Android (Assembly?)? Or does the fact that ...the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine. limit the speed of the software so drastically that it makes implementation of highly efficient software such as a decent XviD decoder impossible? I look forward to hearing your input on this, and would be very thankful for links to resources concerned with the issue of performance and efficiency in Android applications. Thanks in advance! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
