Forgot your password?
typodupeerror
Android IOS Programming Software

Android Needs a Simulator, Not an Emulator 167

Posted by Soulskill
from the simulated-grass-is-greener dept.
An anonymous reader writes Jake Wharton, Android Engineer at Square, has written an article about one of the big problems with building apps for Android: developers need a simulator for testing their software, rather than an emulator. He provides an interesting, technical explanation of the difference between them, and why the status quo is not working. Here are the basics of his article: "A simulator is a shim that sits between the Android operating system runtime and the computer's running operating system. It bridges the two into a single unit which behaves closely to how a real device or full emulator would at a fraction of the overhead. The most well known simulator to any Android developer is probably (and ironically) the one that iOS developers use from Apple. The iPhone and iPad simulators allow quick, easy, and lightweight execution of in-development apps. ... There always will be a need for a proper emulator for acceptance testing your application in an environment that behaves exactly like a device. For day-to-day development this is simply not needed. Developer productivity will rise dramatically and the simplicity through which testing can now be done will encourage their use and with any luck improve overall app quality. Android actually already has two simulators which are each powerful in different ways, but nowhere near powerful enough."
This discussion has been archived. No new comments can be posted.

Android Needs a Simulator, Not an Emulator

Comments Filter:
  • The author clearly needs to get his terminology straight.

    What he describes is more like a "bridge" between the computer and the android device, than a "simulator".

    • Re: (Score:2, Informative)

      by Anonymous Coward

      You clearly need to get your terminology straight.

      What you describe as a "bridge" is more like a house for homeless people.

      But simulator is the correct terminology... the way you might want to implement it doesn't make any difference.

      • So if Apple can sim run iOS apps in OSX, why cant they officially, run all iOS apps (w/arm emu) inside OSX, so that I can run full screen iPad apps in OSX, or small iOS apps as desktop widgets.

        Dont give me the crap of ohh the iPhone app will look crap full screen, duhhhh , run it in a window thats scalable.

    • by Darinbob (1142669)

      This is more of an platform simulator, something that an application can run on in mostly the same way it would on the real device.

      From my perspective, I find the opposite problem. Too often all I see are simulators, and the application people are happy, but emulators are what is rare and far more practical for uncovering actual problems in the lower level code. Ie, a simulator often runs a task to completion, whereas an emulator may have preemptive context switches that causes things to break if the appl

      • In any case, the terminology is confusing. An emulator is a simulator, whereas the reverse is not true.

        This is like saying "monkeys versus animals" or "apples versus fruit", putting them on equal footing.
        It just doesn't make any sense this way.

  • by Anonymous Coward

    Can't http://www.android-x86.org/ be used in one of avaialable VM frameworks?

  • by thatkid_2002 (1529917) on Wednesday June 18, 2014 @05:28AM (#47261035)
    Android is available for x86 these days and you can use hardware acceleration [android.com] (CPU and GPU). Just set it up and get near-native performance. Or if you have an Android phone just `adb install -r blah.apk` what more can you want?
    • by Lordpidey (942444)

      Android is available for x86 these days and you can use hardware acceleration [android.com] (CPU and GPU). Just set it up and get near-native performance. Or if you have an Android phone just `adb install -r blah.apk` what more can you want?

      One that works on most CPUs.

    • by thegarbz (1787294) on Wednesday June 18, 2014 @06:07AM (#47261137)

      I think what the author is referring to is an Android system which integrates into the tool chain and can be directly controlled by the tool chain / IDE.

      Yes the android debug bridge exists, but it's quite a beast to use and I don't believe the authors comments refer to a problem of simply running an app on a phone.

    • by cerberusss (660701) on Wednesday June 18, 2014 @06:31AM (#47261203) Homepage Journal

      "Just set it up" isn't as easy as you make it out to be. I just tried it in Android Studio.

      First, you have to install a 3rd party kernel extension (from Intel). Then you have to configure an AVD with the new x86 value for the CPU/ABI field. It didn't appear for some reason for my target "Android 4.4.2". After looking around, I found another download in the Android SDK Manager called "Intel x86 Atom System Image", let's download that. The documentation mentions this, but I glossed over it. OK, back to the AVD manager and create a virtual device.

      Now I finish it, and run the app. Running the app takes 39 seconds, as Grails reports (about 5 seconds, if that, on Xcode for the iOS port of our project). It asks where I want to run it, pick the new AVD and click Run. It starts Android but not the app.

      Weird. OK, so I run it again with the simulator running. The option "choose a running device" cannot be selected. That's strange. I pick the new AVD again and unfortunately, it starts another copy. Shit. I let it boot but notice it's really slow as usual -- ten minutes later it's still booting. I check the already running copy and click around. Slow as hell as well. Apparently it's not accelerated at all!

      At this point, I'm ready to give up and go back to testing on a device again.

      The above is tested on a 2013 MacBook Air with 8 gigs of memory.

      • by The1stImmortal (1990110) on Wednesday June 18, 2014 @06:48AM (#47261249)
        How about Genymotion? http://www.genymotion.com/ [genymotion.com] - uses VirtualBox as the underlying x86 VM layer, instead of AVD + HAXM. Supports a few additional sensors too (either emulated or passed through from real hardware if it has them)
        • Re: (Score:3, Informative)

          by sheltond (252356)

          Yes. Genymotion is great.

          Really fast, lots of different system images for different Android versions and device configurations (screen sizes and densities, input devices, etc), integrates nicely with adb and Eclipse (I haven't tried it in Android Studio, but I imagine it works equally well).

        • I agree: indeed Genymotion fills in this gap perfectly, and I recommend it strongly for any Android dev. I also found Genymotion devs to be amazingly prompt in responding to bug reports. (I have no connection the company, am just a fan of their work.)

          But it's still surprising the that official Google toolkit doesn't have anything like it. Google, get on board! Just buy up Genymotion or license their tech.

          By the way, emulation still has its uses in some cases... it's of course best to have both.

      • by robmv (855035)

        It is a problem of the Android tools for OS X and Windows, on a Linux distribution with a compiled kernel with KVM virtualization enabled (any modern distro), you only install the x86 image and start it without any other install or configuration needed, who would have said that using Linux would be easier than Windows hehe. The only downside is that if you start using KVM VMs, other virtualization solutions like VirtualBox can not be used at the same time, so if you need a Windows VM for your daily work you

        • by TheSunborn (68004)

          Yeps. I can confirm that. On linux it just works with Eclipse, and my emulator is running my software faster then the Android device I am testing on. (But I am testing on an old Android 2.3 device. I am sure a new Android device would beat my emulator).

        • KVM and VMWare Player can run VMs simultaneously without any problem.

      • I have pretty much exact same experience. It is so unbelievable slow, I don't know how anyone does serious development with it. I keep trying to use the emulator but every single time I end up going back to just testing on an actual device. I could understand it being like this for the first year or two after android was launched, but this late in the game I seriously expect something much better.

      • Wow.. dude you are lame ok? HAXM is an option in the SDK. Is it that difficult to check the box? And creating an AVD is not exactly rocket science. I use IntelliJ (as opposed to Android Studio which came out later) and have had no issues with emulation. In fact I often have a physical device and one or more emulators attached to ADB. And one click to build and send to the 'device' isn't too hard either. On any modern PC the x86 emulator runs without a hitch.

        As to your "issue" with an emulator not

        • No, it's not rocket science. And if it worked now, it would be okay. But it doesn't. I ran through all the steps, and the simulator starts but it's not the x86 emulator for some reason.

          • AVD
            pick a device
            an API
            select Intel Atom(x86)
            fill in the other blanks as appropriate

            SDK
            make sure you have installed an Intel x86 Atom System Image for the API you are interested in
            make sure you install the HAXM extra (Intel x86 Emulator Accelerator)

        • by Bogtha (906264)

          Stop making excuses for a shitty UX. Android development is an utter pain in the arse in a lot of ways and as long as people like you make excuses instead of complaining about it, it's going to continue to be an utter pain the arse for years to come.

  • Android runs on java code. It seemed incredibly strange to run an emulator to run a JVM to run code.
    • Re: (Score:2, Informative)

      by Anonymous Coward

      Very much in Android, including application code, is not Java.

    • It shouldn't be too surprising that it runs well with Java. Embedded is where the first Java inroads were made. Recent VMs make the performance pretty sweet, once you get going.

      Running the JVM on an emulator, however, is less than optimal: "it's turtles all the way down".

      I understand why they did it but, if there are still serious performance problems with it (which wouldn't be surprising - phones are growing in performance faster than PCs) then they probably need to go the simulator route (even though t

    • Android runs on java code. It seemed incredibly strange to run an emulator to run a JVM to run code.

      1. As another said, Android does not provide a JVM. They provide the DalvikVM which is different in many ways from the JVM including the bytecode instructions used, as well as many classes that are present the JVM but not in the DalvikVM and vice versa. Using the JVM with an additional set of classes works out well for development more by-chance and the nature of the Java Language than anything else.

      2. Many Android Apps uses native libraries to speed up the application - e.g there is a lot of code in And

    • by Wdomburg (141264)

      Dalvik is its own VM and bytecode specification.

  • So much wrong (Score:3, Interesting)

    by Anonymous Coward on Wednesday June 18, 2014 @05:36AM (#47261059)

    Apple's simulator is unusable because it's a simulator. If it works on the simulator it tells you virtually nothing. If it doesn't work on the simulator it tells you virtually nothing. You need to run on the actual device. Oh what I wouldn't give for an emulator where if it ran on the emulator it would be some guarantee to run on the real device too, and if your code doesn't run on the emulator it would be some guarantee your code was broken (not that the simulator just doesn't support some feature).

    So yes, let's applaud Apple's cheap-ass simulator approach which is unusable, and emulate it [heh] on Android.

    • by Anonymous Coward

      Apple's simulator works very well for 90% of the apps, and if you need to use sensors, have particular graphic demands, or you're going to push the hardware to its limts, you're likely to use a real device for testing anyway.

      • by Anonymous Coward

        have particular graphic demands

        My "particular graphic demands" are that I do all my drawing using OpenGL. As a result I gave up even trying to use the simulator years ago; you have no clue how it will perform on the device until you run it on the device (lowest common denominator being iPhone 3GS w/ OpenGL ES 2.0). Same goes for anything performance-oriented. And if you get a drawing bug on the simulator maybe it'll work fine on the device, and if it works fine on the simulator you might get a black scre

        • That's a fair point. However, to what extent do these issues exist because the iOS simulator is a simulator rather than an emulator? An emulator might have broken OpenGL support, same as the simulator. And for performance-related stuff I'd prefer a real device over either.

          By the way, the author of that article does not IMHO make a strong point for simulators. He seems to have a lot of problems with the Android development environment, some related to performance and reliability but many related to u
          • by Immerman (2627577)

            Would not an emulator be far more likely to run the actual device OS and APIs? If the software libraries are the same then the emulator is simply a standard device running on virtual hardware, and can be expected to be as compatible with real hardware as various hardware devices are with each other.

    • Re:So much wrong (Score:5, Insightful)

      by JaredOfEuropa (526365) on Wednesday June 18, 2014 @06:26AM (#47261195) Journal
      Virtually nothing? I'd say that the simulator covers about 95% of my testing and diagnosis needs. I only have to resort to running on a physical device when I have to test stuff related to the on-board sensors, camera, or push notifications. So far I've found 1 case where the simulator did not behave as expected. If it works on the simulator, chances are it'll work on the device. If it doesn't work on the simulator, in almost all cases you will be able to use the simulator to diagnose and fix the issue. I should note that I do not do game development; I've no experience in writing apps with high performance 2d/3d graphics.

      With that said, I always test release candidates on various types of real devices.
      • by Anonymous Coward

        I should note that I do not do game development; I've no experience in writing apps with high performance 2d/3d graphics.

        Well, then, when you try doing those things you'll understand why my comment is true.

        • Re:So much wrong (Score:5, Informative)

          by coinreturn (617535) on Wednesday June 18, 2014 @07:23AM (#47261385)

          I should note that I do not do game development; I've no experience in writing apps with high performance 2d/3d graphics.

          Well, then, when you try doing those things you'll understand why my comment is true.

          Well, I won't. I have five games in the App Store and I have always used the simulator for development. It works very well. For me, it is VERY rare that something works on one while not working on the other.

          • by _xeno_ (155264)

            Bullshit. You don't even need to be doing game development for the simulator to be useless.

            Every experience I've had with the simulator has been that it's entirely useless for determining how the code will run on a real device. I mean, hell, you don't even have actual iOS running on the simulator, you're running a Mac OS X binary!

            The simulator is effectively WINE for iOS: it reimplements the iOS APIs under Mac OS X, and the toolchain compiles an x86 binary instead of an ARM binary. No one should have to exp

            • by rjstanford (69735)

              The simulator is very useful for developing all sorts of apps. The fact that it didn't work well for yours because it was hiding some poorly optimized code doesn't mean that a huge majority of apps don't benefit from it.

              Most apps in the app store are not the latest and greatest video epic.

              If you had a "bog-standard iOS app that was a very simple UI in front of a website" that has complex long-running code in the UI thread, or for that matter complex code that takes "nearly a minute" to run in the first pla

              • by _xeno_ (155264)

                If you had a "bog-standard iOS app that was a very simple UI in front of a website" that has complex long-running code in the UI thread, or for that matter complex code that takes "nearly a minute" to run in the first place, well ... that's not the simulator's fault.

                But the fact that it hid it until someone finally tried it on a device is the simulator's fault.

                And you've never had websites that did anything even somewhat complicated in JavaScript, huh? Since you aren't allowed to run interpreted code on iOS, it had to be redone in Objective-C, and the initial version turned out to be very slow. (Think "charting.")

                I mean, sure, we could have just embedded a webpage and done it that way, but the existing JavaScript was already unacceptably slow or we wouldn't be looking

                • by drinkypoo (153816)

                  But the fact that it hid it until someone finally tried it on a device is the simulator's fault.

                  That still doesn't make the (so-called) simulator useless. It means that it is not a complete replacement for another solution, but that's not the same thing.

                • by jittles (1613415)

                  But the fact that it hid it until someone finally tried it on a device is the simulator's fault.

                  I hate to break it to you, but an emulator isn't going to fix that either. The emulator will perform more slowly than the simulator, but it is still ultimately running on a completely different system than your final product. Perhaps your app is IO bound and you're running on a faster IO device than the target? The point of a simulator or emulator in this case is to verify your proof of concept. Not to say "I did my job." And if you already knew there was a performance issue on the actual hardware with

                • by rjstanford (69735)

                  But the fact that it hid it until someone finally tried it on a device is the simulator's fault.

                  The same thing would happen if you'd tested on an iPhone 5S and then your users tried to run it on an iPhone 4. Is that their fault also?

                  And you've never had websites that did anything even somewhat complicated in JavaScript, huh? Since you aren't allowed to run interpreted code on iOS, it had to be redone in Objective-C, and the initial version turned out to be very slow. (Think "charting.")

                  Odd to hear this from you, since we deploy many apps written extensively in JavaScript, but do go on.

                  I mean, sure, we could have just embedded a webpage and done it that way, but the existing JavaScript was already unacceptably slow or we wouldn't be looking at making an iOS app, now, would we?

                  Aha! Sounds like you had slow code in one language and replaced it with slow code in another language. FWIW, there are plenty of free JS charting libraries that run really well generating complex charts blindingly fast even on very old iOS devices.

                  What's that saying abou

            • Re:So much wrong (Score:4, Insightful)

              by coinreturn (617535) on Wednesday June 18, 2014 @10:01AM (#47262263)

              Bullshit. [snip] The simulator is entirely useless for developing an actual app.

              No, what I said is not bullshit. In my experience, it works great. Yours differs. That does not make my experience bullshit. Perhaps you suck at programming.

    • I make more business apps and I rarely see any differences between actual device and simulator. Sure, once in a while something behaves slightly differently but not enough for me to want something that will run much slower.
      I know I can code up 99.5% of it with the simulator, the last .5% I may need the device.

      Now this is just somewhat basic apps, not using any sensors or graphics.

  • by Anonymous Coward

    I use Jetbrains' IntelliJ IDE for Android development. Using it I can debug using an actual tablet plugged in via USB. Shift-F9 brings the project up to date, packages it up, ships it over USB to the tablet, and relaunches it. You can set breakpoints, step through your app, look at variables, in short, everything you could do if it were a native local app. AND at the full speed of your tablet. The ONLY way to debug Android apps.

    • by kav2k (1545689) on Wednesday June 18, 2014 @06:08AM (#47261143)

      Great. Now, do you have a spare tablet around for every target android version?

      • Re: (Score:2, Informative)

        by Anonymous Coward

        Great. Now, do you have a spare tablet around for every target android version?

        This is the general problem with Android in any case, since versions are not kept up to date on all devices, not all devices have the same resolution, CPU capabilities, graphics performance, input devices, cameras, accelerometer, GPS hardware, touch screen capability, keyboards, and so on and so on.

        You will always need to test on the actual hardware to be sure your monster Intel box and nVidia video cards aren't giving you a false idea of how fast your app is, or that your app doesn't suck, or that it'll wo

      • by drinkypoo (153816)

        Great. Now, do you have a spare tablet around for every target android version?

        You don't need that. You just need one device that is easily reflashed to multiple versions, maybe two devices. A Nexus 7 (1st or 2nd, either way) will cover all the new versions, for example. Given the ease of swapping factory images, it's a fairly minor annoyance.

        Since there are already adequate emulators provided for basic compatibility testing, that will get all but the most diehard developers through. Those people can buy more hardware with profits from some lesser successes if they are truly beginning

      • You can make any number of virtual devices which will get you stock android on the most widely used device configurations. Its not hard at all because AVD manager comes with predefined examples you can copy and then modify if you so chose.

  • by Anonymous Coward
    • This was one of the best features I found when developing apps for FirefoxOS. Actually, you don't really need much of the FirefoxOS when doing the design job since the HTML/CSS will render with Firefox quite exactly as it would in any FirefoxOS phone.

      • by rjstanford (69735)

        Actually, you don't really need much of the FirefoxOS when doing the design job since the HTML/CSS will render with Firefox quite exactly as it would in any FirefoxOS phone.

        What, both of them?

  • by MichaelSmith (789609) on Wednesday June 18, 2014 @05:49AM (#47261083) Homepage Journal

    Android apps already run on Linux. Why can't I just fire them up on Ubuntu? The VM should br portable.

    • Perhaps if your PC runs on an ARM processor, it would be simple.

      I'm not sure Ubuntu has an ARM iso.

      • It would be pretty poor if the VM couldn't be compiled for i686 or AMD64.

      • by c (8461)

        Perhaps if your PC runs on an ARM processor, it would be simple.

        ARM emulation under x86 is feasible. Google "libhoudini". Whether it's simple is another question, but the pieces are there.

      • Of course Ubuntu supports ARM
        http://www.ubuntu.com/download... [ubuntu.com]

        I run Debian on my ARM board.

      • by hairyfeet (841228)
        Go to any Chinamart site and you can pick up an ARM dual core desktop box for less than $50 USD and while they come with Android from what I understand most can run Debian as well so if you need an ARM box to do your coding on they really aren't hard to come by.
    • Android apps already run on Linux. Why can't I just fire them up on Ubuntu? The VM should br portable.

      I've wondered this too.

      I guess one would have to provide an X11 based inpout and output driver for the graphics stack, at the minimum and run it in a chroot.

      To make it good, you'd probably have to bridge notifications between the two systems.

      Given it sounds easy and hasn't been done, I strongly suspect it is much harder than it ought to be. Given that most bits of android end up seeming wierd and badly desi

  • by Anonymous Coward on Wednesday June 18, 2014 @05:52AM (#47261093)

    Given the open source nature of Android, what I don't understand is how no project so far has integrated the Android runtime with the Linux desktop. Licencing issues maybe? Leave it in a separate PPA.

    It would be amazing to be able to run Android applications in Linux seamlessly, ideally integrated with the indicators and notifications provided by the OS.

    That would be a killer feature (and would expand the library of games available for Linux by 1,000,000%), in addition to other applications.

    I know it is possible to emulate Android, there are some options for this, but it is not about emulating a phone in my computer; I already have a phone. What I would love is to run Android apps in it (of course, as long as that software includes x86 libraries, or there is an emulation layer available).

    • Guess the project of your dreams needs a Summer of Code at Google.
      Propose, propose, propose...

    • I always wonder the same. But probably the answer is Canonical wants its own Linux phone than powerful integration with Android. Should be, in current days, a killer flag: "hey, my Linux distro runs Android apps, and integrates smoothly with Android phones".
      • by psionski (1272720)
        What does Canonical have to do with anything?
      • by tlhIngan (30335)

        I always wonder the same. But probably the answer is Canonical wants its own Linux phone than powerful integration with Android. Should be, in current days, a killer flag: "hey, my Linux distro runs Android apps, and integrates smoothly with Android phones".

        Well, the problem is Android.

        You see, the current Andorid OHA agreement makes it impossible for an OEM that ships Android phones to ship any other phone that can run Android apps that does not run Android. So if you make an Android phone, you're blocked

    • Actually that was the goal of the AndroVM [androvm.org] project. Unfortunately, that project became the commercial Genymotion [genymotion.com] project and the goal doesn't appear to be desktop integration, but instead a developer tool. You can use it to run apps, but I don't see any specific integration features.

      Otherwise, there is BlueStacks [bluestacks.com], but it runs on Windows and Mac, but not Linux.

  • by rklrkl (554527) on Wednesday June 18, 2014 @06:08AM (#47261145) Homepage

    Whilst playing around a little with Eclipse and the Android SDK, I found it much easier to just plug in my Android tablet (or it could be an Android phone or both) and download/run the app on that. You get to check rotation, multi-touch, camera etc. a lot more easily this way and it's just as easy (if not more so) than running the emulator. Of course, there could be Android devs without any Android devices at all, but I suspect that's a tiny minority.

    The main use of the emulator is probably just to test different screen dimensions render OK - I personally wouldn't use it during the bulk of development though.

    • by batkiwi (137781)

      Honest question, I haven't tried, but do breakpoints work when you're running on the device itself?

      (Eg does it have a remote deploy/debug over USB mode?)

    • by GNious (953874)

      I have my jolla development set up to simply send any program I working on straight to a phone, and run there as part of the compile+run procedure.

      With SSH access, QTCreator is basically SSH'ing in, deploying+running the app, and giving feedback straight back to my screen, while I have a separate shell running with SSH into the phone and while I'm reviewing the behaviour of the app directly on the phone.

      No need for simulators, emulators or other -mulators :)

    • by bluescrn (2120492)
      Deployment to devices gets rather slow when dealing with large apps (e.g. games with lots of assets), though. Slow iteration time kills productivity. I want the absolute minimum time between editing a line of code and being able to test/debug that line of code.
    • by DerPflanz (525793)

      You can also setup a large phone to render smaller screen resolution, using adb, for example

      adb shell am display-size 640x480

      I have never ever used the Android emulator for testing, because it is annoyingly slow and a real device works just fine.

  • Pretty simple and super fast. Now, I suppose that the Android Development environment could include a stripped down virtual machine, but no one has done it yet (I think the current emulator uses QEMU to actually emulate ARM). http://kamyanskiy.blogspot.com... [blogspot.com]
  • Toooooo Slooooow (Score:4, Interesting)

    by EmperorOfCanada (1332175) on Wednesday June 18, 2014 @07:33AM (#47261415)
    I have a bonkers fast machine with SSD, gobs of memory, CPUs on fire, etc. Yet running the android emulator is go off and make a sandwich time.

    I do 100% of my testing on actual devices which is not at all how I work with iOS. With iOS I only occasionally test my code on an actual device as there are occasional differences between the simulator and the actual devices.

    Also the android is all about settings, settings settings, instead of asking me if I have a keyboard, GPS, etc. What I would like is a list of the most popular phones. Then I could try out my code on those very phones. Also it would be great if someone had a problem with my app on a specific phone and I was able to quickly select that phone and try out my code.

    I get a feeling that the emulator was not so much aimed at developers of apps but aimed at hardware and OS developers who need this magically perfect emulation. Whereas the iOS Simulator is quite clearly aimed at people who are developing apps. Which oddly enough would be 99.999% of the potential audience.
  • Nothing is stopping you.

    Apache 2.0 please.

  • I am a web developer, now working on Android.
    I use Android Studio (far better than Eclipse). With HAX - hw accelerated execution - enabled and emulator running in fast virtual mode I don't notice much difference between any run/debug on any virtual device and debug/run on a Weblogic/Websphere/Tomcat server on top of some CMS/Commerce Engines.
    Both are slow, but not unreasonably slow.
    May be when the apps get complex there might be a difference.
    I don't see how a simulator will make a huge difference, b
  • I hate to disagree with Wharton (look up his work, the man is a champion) but the Android emulator has already been fixed with HAXM. It's been released into the SDK Manager and only requires copying a file to turn on. Once it's on, the emulator runs at totally acceptable speeds, and provides a much richer environment than a simulator would.
  • by iPaul (559200) on Wednesday June 18, 2014 @08:57AM (#47261721) Homepage

    As I read the comments I find it surprising that people somehow object to this idea because 1) they don't like the terminology, 2) the say the existing emulator is just fine, 3) Apple sucks, 4) If you just do these 37 steps, it works awesome on my machine and 5) did I mention Apple sucks?

    I don't program professionally but I am a tinkerer and I did try my hand at both iOS and Android development. As a noob in both, I found the Apple environment much easier in terms of usability. This is not a plug for Apple, but an observation about how fast the tool chain is able to launch the simulator and step into live, running code. There are obviously things that won't work, but I was able to get going quickly and play with the examples. It was also relatively painless (although there was a lot of hoop jumping) to get the code onto my phone and running.

    I like the Jet Brains based Android development environment. It's really nice to work it but when it comes to actually running the code you wrote, you basically need a real device. The emulator start up time is horrible and the performance while running is terrible. I've tried to get the x86 ABI running on my machine but I didn't notice much of an improvement. Yes, yes, I know, but Apple sucks. I would call the emulator borderline unusable for development and almost not usable for testing because of its bad performance.

    I'd like to try some of the resources he mentioned in the article, but I only found out about them two minutes ago when I read the article. As a noob, I didn't even know they existed. Tools do matter. As Microsoft and Apple have found out, creating really nice development environments is important in capturing mind share. At some point every developer is a noob at something and making easier for the noobs to get going is part of making a platform sticky.

    So let the grammar corrections, the Microsoft sucks, the Apple sucks comments come. It doesn't change the fact that being productive isn't just about which APIs you can memorize, but also about the toolchains and environments you use to write code.

  • Simulators and emulators still aren't as good as the real device. You an argue all you want about why you need one over the other but at the end of the day you really just need to load the app on a device and test it in a working environment
  • Android needs to make it much simpler. I don't want to spend a ton of time configuring a OS. Provide some premade vm's for the Google devices and I can use real devices for the other testing. Make it easier for me to get QA and Business users to do testing, and not a major headache that eclipse setup is.

    • by drinkypoo (153816)

      Android needs to make it much simpler. I don't want to spend a ton of time configuring a OS. Provide some premade vm's for the Google devices and I can use real devices for the other testing.

      Uh, that's what they do. And they give you an ARM VM to run them in.

      Assuming what you really meant is that you literally want to run android in vmware, you can get android-x86, and install it to a virtual machine. Last time I did this, it even worked, more or less. Sadly, they never really finish a release, so android-x86 is never actually very good. I have however installed it on an Atom netbook before, and had everything work AFAIC(ould)T. But now you're going to have to not just build for x86, but also

  • The Android SDK/platform sucks big donkey dongles. I won't get into why here. But I'm an android developer and out of everything I've learned it is the worst.

    At least with Qt you can write apps for every major platform, desktop or mobile. What I've done with it (successfully) is develop apps using my desktop, then add the tool chain for mobile compiler, and compile for that platform. That way, the toolkit becomes the simulator and you don't need to run your app though an emulator or simulator, which saves a

  • I am also and Android developer and this problem is already solved. Android Studio + ADB (included with Android Studio) + Genymotion. You get native speed, lots of sensors to emulate and can even install the gapps packages if you need to test against those libraries (I use them for Chromecast support).

  • Or as Adam Sandler calls it, a "shimulator".
  • Only a poor craftsman blames his tools.

Any sufficiently advanced technology is indistinguishable from a rigged demo. - Andy Finkel, computer guy

Working...