This is related to question Android Emulator vs Real Device
What is the current state of art of Android emulators and what are the differences that developers should be aware of. I'm working on an app that uses bluetooth and thinking of adding a feature related to phone calling. Since I can't afford to test on all real devices so what should be the guidelines for developer to test such apps on emulators ?
Genymotion rocks. According to the blog post of Cyril Mottier it is even much better then the hardware devices.
http://www.cyrilmottier.com/2013/06/27/a-productive-android-development-environment/
I test basically everything on several real devices. The only thing I use an emulator for is making sure layouts look good on the configurations I don't have available(I don't have a 7" tablet, for instance). This is only after just about everything else is done.
Functionality is going to be nearly the same on any real device, and the emulator is no guarantee, since it doesn't seem to act like any real device in some cases(openGL, for instance).
Testing usability on a desktop with a mouse just doesn't make sense, unless you're writing something that going to be using that input method. There's a big difference between swiping with a finger and click-dragging with a mouse.
Even if you have the fastest emulator/virtualizer in the world, how can it be any faster than just picking up the phone next to you?
Related
I don't have any other devices to use for testing. I'm looking to test apps that I develop on my own Android phone but wonder if I could mess up my phone if I accidentally write some bad code.
Also, if I use emulators, are they good representations of real phones?
You should consider BlueStacks
This worked for me - as long as multi-touch isn't necessary.
You'll find that an emulator works fine for most things and are a good representation of the specific phone, however they are often much slower than physical devices. IF you have your own android phone then I'd highly recommend using it for the convenience and the bonus of actually having tested your app on a real device.
We want to place a device in a store that operates as sort of a kiosk device. As in customers walk up to it and start interacting with our custom app. The app could be developed for Android or the iPad, so I'm trying to decide which one to use and would like comments on the following ideas:
Is it possible for Android or iOS to access services over the USB port? This would enable us to disable the network.
Is one particularly better for 24 hour always on?
I like the iPad as I think its supply will be more constant as we move forward and need to replace devices due to ones gone bad. Also, our app will probably work on future generations of the iPad. With Android, I'm not sure there will be that sort of consistency from the tablet vendors.
Kiosk mode? I think with the iPad by putting it in a kiosk case that removes access to the home button and turning on the restrictions we'll get what we want. What about Android? I'd rather not have to get into rooting devices and replacing their firmware.
Remote control? Any way to remotely control iOS or Android in a standard means? Our app will be a client to a master server which will obviously be able to control the app somewhat (when used purely as a display device to a customer, controlled from behind the counter).
My feeling is that neither Android tablets or the iPad is best suited for this. Are there other options?
I will try to answer your points, but know that I am probably biased towards Android, because that is where my experience lies.
With Android 3.1+, at least with the Xoom, you have full USB host capabilities. Things like USB flash/hard drives, keyboards, mice, even digital cameras, all work. If you need custom interop with a USB device, you could go as far as to write a driver for it.
24 hour always on is not good for any device with a battery, but neither is better in this situation.
While android apps are forward-compatible, bad programming practices and/or deviations from "vanilla" Android software and hardware CAN break forward compatibility. That being said, if you grab a Google Experience device like the Xoom, you won't meet as many surprises.
In Android 3.0, the navigation bar is built-in at a low level, and it is not possible for apps to remove it. Therefore, it is trivial for anyone to break a "software nanny."
I know that it is possible to control android devices remotely, but without knowing your specific needs, I can't really offer more information than that.
Good luck!
iPad NOOO believe me I am a convert to Apple for my home and business but when we went to launch kiosk the iPad FAILED Big Time.. Here are a couple of little (Big) issues we ran into.
If the device reboots you cannot auto launch you iPad app since Apple does not allow that.
There is a serious memory leak in the iPads browser. We were running javascript / CSS3 and it cratered intermittently. I literally spent 2 hours "today" on the phone with Apple getting the MAJOR run around. I finally said let me speak to an Enterprise Sales Manager as my project could mean thousands of iPads and I got NO WHERE. One Apple employee even told me they don't have enterprise sales managers.
If those weren't enough even though we are just in the proof of concept phase, we are already getting request for other options. These other options are going to require access to the OS which Apple yea right. We are moving to Android immediately.
Sorry Apple I love you but you loose here.
If your using an Ipad you should consider if it can support the power for the USB thing. Watch this Using Powered USB Port
Your idea about putting the tablet behind another piece of glass/plastic is neat. To then deal with remote controlling, you might consider doing some Bluetooth programming.
My mobile development has been primarily with iOS, so I am biased toward that SDK. I will mention that the data/sync/charge port for iOS has (I believe) never changed. Your Gen 1 iPhone sync cord works on your iPhone 4... and your iPad or iPad 2. So, in terms of third party hardware, you may see more consistency with Apple.
I haven't found a good answer regarding whether it is easier to do Bluetooth programming for iOS or Android, but I think to stay cost-effective, you might see which one is more open to third-party devices. Here is an SO post/answer about iOS and third-party Bluetooth devices; I've not found anything on Android regarding third-party Bluetooth remotes, but considering a lot of hardware running Android is third-party, your chances from a naive perspective seem pretty good. Here's the Android Bluetooth API.
Buying an iOS or Android handheld to remote control an iOS or Android tablet does seem a bit steep, but then again, maybe not. Cost also depends on your ratio of remotes to tablets. 1:1? 1:N? N:1? N:M?
The lowest end iPod goes for $229 as of May 20, 2011. Android does have more variety in terms of hardware. You may be able to get a cheap Android phone with no service plan to act as a Bluetooth remote for an Android tab.
I have provided a solution for the kiosk mode using iPad here Lock-down iPhone/iPod/iPad so it can only run one app
I am afraid that I don't really know for Android if the same thing is possible.
To address the issue of crashing applications you can use an exception trampoline (see discussion here https://blog.compeople.eu/apps/?p=275) to catch the crash and reboot your app.
If the entire device is restarted however then other apps that are on the device can be started and will subsequently be locked in.
To answer your other points:
You can use a configuration profile to control network access. Force it to use a VPN or Proxy that only allows your custom app with embedded credentials to use. That way other network access can be prevented.
Your concern over future compatibility is spot on. The Android marketplace is so fragmented then maintaining a fleet is difficult.
If you have an app that is behaving as a server and is locked in then remote control is possible.
We manufacture tablet kiosks that support both android and iPad devices. In fact we are the only iPad kiosk that has achieved apple approval.
Generally speaking i think you will have an easier time with an iPad as the software and hardware will remain more consistent over time. Which is important if you have to change out a fault unit or deploy more kiosks 6 months or year from now when the original device is no longer manufactured.
I am trying to do a demo on a android device, but the screen is too small so is kinda hard to do a demo let say in a meeting room with 12 people. Although I can pass the device around the table or just simple borrow or get more devices for the demo purposes.
I understand there are devies where you can buy special USB converter to do TV-out like in iPhone, and some specific devices on Android (e.g. Motorola Incredible?) But I have to demo on a specific device where it runs standard Android build.
I understand I can do it on Android emulator but the screen refresh rate is too slow, as it will send the wrong message to the audience that the app is slow. (Or there is a way to increase the screen refresh rate for emulator?) Furthermore the emulator doesn't support multitouch. (Or am I wrong?)
Not sure if anyone
You do not have many options.
You can use Droid#Screen, but the refresh rate on it is maybe 6fps. I am not aware of any other software projector that is faster.
You failed to mention the "specific device" that you are using, so I cannot comment on whether it has TV-out capability. The HTC DROID Incredible and the Samsung Galaxy S series support composite output -- I use the DROID Incredible for this purpose a fair bit. Most of the devices that have HDMI output only support it for certain built-in apps, such as the video player.
You can rent or purchase a device projector, like an ELMO. These are fairly expensive pieces of equipment purchased new, though I see a handful of used ones on eBay at interesting prices (though watch out -- many seem to lack the AC adapter).
If you can delay the demo several months, you may be able to use a Google TV.
And that's about it, AFAIK.
Or there is a way to increase the screen refresh rate for emulator?
Get a faster computer.
Furthermore the emulator doesn't support multitouch. (Or am I wrong?)
I am not aware of a way to simulate multitouch with an emulator, though I have not gone looking for a solution there.
If you have an Galaxy S3 Android mobile phone, you can use Mobizen. It's free and the screen refresh rate is relatively good. You can control you mobile phone from you computer using your mouse and your keyboard. It's working using USB, 3G or Wifi connection.
I have used this Android screencast tool: http://code.google.com/p/androidscreencast/ in past demos, but again the downside is the relatively slow refresh rate.
If you have a rooted device, you could try Droid VNC Server (it's on the market). The refresh rate isn't too bad, but I certainly wouldn't want to demo full motion video or an arcade game on it.
You could also get a webcam, rig it up with a tripod. Something like this. Downside is your hands will be in the way, maybe issues with lighting and/or focus. Upside is a decent refresh rate.
I started developing android applications. And am testing with the android emulator. Do I really need android phone before releasing it for public usage?
Short answer No. You can test and build a android application package with the SDK and an emulator. But I would say there are usually many things which it would be wise to test on a device.
Personally I have noticed that the emulator does not give a good indication of response times for UI controls. It is usually necessary to move functionality which has long processing times into background threads to maintain user interactivity without the 'force close' pop-up. Testing the effectiveness of your UI responsiveness must be done on a phone to be meaningful.
Network connectivity is another aspect which can be vastly different on a phone, 3G or wifi.
Device sizes and Android platform versions can be tested effectively on the emulator.
Some phone allow hot-swapping of the SD card (replacing the SDcard without turning off the phone). I am not sure how to replicate this on the emulator.
There may be many more things which may only become apparent when using your application on a real device. I would strongly suggest to always test under real conditions when feasible for any commercial project.
From a technical perspective there's no reason why you can't develop purely on the emulator. You're not going to be able to test on every available device, so there's always going to be possibility of device specific bugs that you've missed.
However, I'd strongly recommend getting an actual phone to test your application on.
For me the biggest difference between an actual device and the emulator is the difference between using the interface with your fingers and using a mouse. Interactions which make sense in the emulator sometimes don't work as well when you start using touch on the screen. So if you develop purely on an emulator you'll won't lots of little improvements to your UI that would obvious when you used your app on a phone.
You can't feel a real app in your hands until you have a real phone. (I'm telling you as an Android developer)
So, developing w/o real phone is possible, but real phone gives you a lot more experience, fun & usefulness.
It depends on what type of application you're developing, for serious ones you need at least one device to test it on. For complex applications you would need a range of devices, for example with or without hardware keyboard, different navigational button etc. For basic, simple applications you'll probably do fine with just the emulator.
I would imagine with games you would definitely need to test on real devices.
Thanks to you all. I am going to get HTC Legend and test it, so that I can hope that my apps can be used by others :)
You guys suggest me HTC Desire or HTC Legend?
I am looking to write an Android app for a device that has not been released to the market yet, and so I will not have the hardware to test upon. I have created an AVD (Android Virtual Device) with as much information as is currently available on the web, so assume that this is as like the device as is possible to get.
However, does anyone have any tips or ideas to make the process of developing for this platform as easy as possible? My current apps have been for personal use on my own phone, so can test performance on the hardware etc. which is obviously not possible in this case. Any gotchas to watch out for (apart from the possibility of the device never being released..!!)
Just follow the SDK.
AVD behaves similar to a real device. I really can't think of something it behaved different on a device and on the AVD.
The only device that brought me trouble is the HTC Hero, first phone with HTC Sense. It didn't follow the SDK and they were calls that weren't there. Newer phones with HTC sense doesn't have this issue, as far as I can tell.