Android Needs a Simulator, Not an Emulator 167
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."
simulator? (Score:2)
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)
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.
WINE , or AINE (Score:2)
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.
Re: (Score:3)
Did you read the article? He defines simulator as a layer between the application and the OS.
I didn't RTFA, but let me point out that his definition is one way to implement a simulator. Let me summarize it for you:
Simulator: functionality, what it does.
Emulator: function, how it does.
A simulator mimics the real thing but isn't.
Both do it, only the objectives are different.
Re: (Score:2)
You have it exactly back asswards.
A simulator simulates how and emulator emulates what.
If I develop an exact description of the hardware down to the individual registers and control paths, that is called a simulator.
Ah, I see, when I control a virtual airplane the program is behind the scenes calculating all the mechanical, electrical, and {aero,hydro}dynamical forces, from the engine, from the control cables, from the landing gear, from everything, all the time, so we can call it a flight simulator. Oh wait, it doesn't! It just makes a rough estimate of the aerodynamical forces, to what you would expect it to behave. Then according to your (wrong) definition, we should call it a flight emulator.
Re: (Score:2)
According to Wikipedia and vocabulary.com:
Simulation
Simulation is the imitation of the operation of a real-world process or system over time.
Emulation
In computing, emulation is the technique used so one machine gets the same results as another.
So I stand by everything I've said, including that you're wrong.
Re: (Score:2)
That would be called documentation, actually :^).
An emulator is a simulator that simulates another computer (an algorithm that's Turing complete - that is, can be made to compute any computable algorithm with the right input). A simulator is an emulator that emulates some non-computer process. And the only thing a Turing machine can do is run one of these.
The article is talking a
Re: (Score:2)
If I develop an exact description of the hardware down to the individual registers and control paths, that is called a simulator.
By that definition all good emulators out there are simulators.
If you simulate the logic, it's a simulator. If you don't, it ain't. If it emulates the functionality, it's an emulator. If it don't, it ain't. Arguably, a simulator is an emulator, but an emulator isn't necessarily a simulator. Some things could be referred to either way, and the choice of term would depend on the situation.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:1)
My takeaway from this is: handhelds need a desktop PC.
Who could've thought!!? Are you listening, Ubuntu, Gnome?!!
Android in virtual machine (Score:1)
Can't http://www.android-x86.org/ be used in one of avaialable VM frameworks?
x86 Android Virtualisation: native performance! (Score:5, Informative)
Re: (Score:2)
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.
Re:x86 Android Virtualisation: native performance! (Score:4, Interesting)
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.
Re:x86 Android Virtualisation: native performance! (Score:5, Informative)
"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.
Re:x86 Android Virtualisation: native performance! (Score:5, Informative)
Re: (Score:3, Informative)
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).
Genymotion (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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).
only a problem with virtualbox (Score:2)
KVM and VMWare Player can run VMs simultaneously without any problem.
Re: (Score:2)
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.
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:2)
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)
Re: (Score:2)
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.
It always did seem odd to me. (Score:1)
Re: (Score:2, Informative)
Very much in Android, including application code, is not Java.
Re: (Score:1)
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
Re: (Score:2)
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
Re: (Score:2)
Dalvik is its own VM and bytecode specification.
So much wrong (Score:3, Interesting)
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.
Re: (Score:1)
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.
Re: (Score:1)
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
Re: (Score:3)
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
Re: (Score:2)
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)
With that said, I always test release candidates on various types of real devices.
Re: (Score:1)
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)
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.
Re: (Score:1)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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)
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.
Re: (Score:2)
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. .5% I may need the device.
I know I can code up 99.5% of it with the simulator, the last
Now this is just somewhat basic apps, not using any sensors or graphics.
Emulator? Simulator? Pfffttt... (Score:1)
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.
Re:Emulator? Simulator? Pfffttt... (Score:4, Insightful)
Great. Now, do you have a spare tablet around for every target android version?
Re: (Score:2, Informative)
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
Re: (Score:3)
And what really sucks is that sales on android are 15% of what is on iOS anyways, yet testing is 10x more on android vs apple. We have about 10 apps in apples app store, and we only have are 2 flagship apps on android. We don't bother testing on every device, I'll test on 3 separate devices and a bunch of emulator configs. Once in a while we get a negative review of "crashes on device x running y" but nothing we can do except refund because we arent blowing out our brains buying every device, nor do we have
Re: (Score:2)
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
Re: (Score:2)
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.
Even Firefox OS has a simulator (Score:1)
Android is playing catch up [mozilla.org]
Re: (Score:2)
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.
Re: (Score:3)
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?
Surrprised it is so hard (Score:3)
Android apps already run on Linux. Why can't I just fire them up on Ubuntu? The VM should br portable.
Re: (Score:3)
Perhaps if your PC runs on an ARM processor, it would be simple.
I'm not sure Ubuntu has an ARM iso.
Re: (Score:2)
It would be pretty poor if the VM couldn't be compiled for i686 or AMD64.
Re: (Score:3)
ARM emulation under x86 is feasible. Google "libhoudini". Whether it's simple is another question, but the pieces are there.
Re: (Score:2)
Of course Ubuntu supports ARM
http://www.ubuntu.com/download... [ubuntu.com]
I run Debian on my ARM board.
Re: (Score:2)
Re: (Score:2)
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
Desktop integration (Score:5, Insightful)
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).
Re: (Score:2)
Guess the project of your dreams needs a Summer of Code at Google.
Propose, propose, propose...
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:3)
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.
I just use a real Android device (Score:5, Insightful)
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.
Re: (Score:2)
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?)
Re:I just use a real Android device (Score:5, Informative)
Yes. You can step through the code on your device from your pc. (Even if connected over wifi. Which is nice, when it works, but it's a little flakey. It's solid over USB though).
Re: (Score:3)
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 :)
Re: (Score:2)
Re: (Score:2)
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.
Windroy (Score:1)
http://www.socketeq.com/ [socketeq.com]
Eclipse + VirtualBox + x86 Android image (Score:1)
Re: (Score:1)
Re: (Score:1)
Toooooo Slooooow (Score:4, Interesting)
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.
So write it, John (Score:1)
Nothing is stopping you.
Apache 2.0 please.
Emulator with HAX (Score:2)
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
HAXM (Score:1)
The resistance to this idea is surprising (Score:5, Interesting)
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.
The resistance to this idea is surprising (Score:2)
Actually I do program professionally. What I mean to say is I don't write iPhone/Android or other Mobile apps professionally.
Just use a phone...... (Score:2)
Where is the vmware app? Need simple testing (Score:1)
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.
Re: (Score:2)
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
Just use Qt, or PhoneGap (Score:2)
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
An already solved problem (Score:2)
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).
Adam Sandler (Score:1)
Simple Rebuttal (Score:2)
Re: (Score:2)
Only a idiot hands someone a screwdriver when they've asked for a hammer.
Re: (Score:2)
There is plenty of alternatives for Android development outside of java. Scala, Clojure, Xtend, Kotlin. They are all decent languages, probably even nicer than Go.
Re: (Score:1)
Someone needs a snickers
Re: (Score:2)
I think the issue is more one with the skinning and mods which the vendors do than the hardware itself as that is easily emulator for just about any device.
I note you mention the Nook. Did you ever have wierdness with the screen dimensions sometimes counting and sometimes not the area where the nook button is? Given it is end of life I decided to not bother putting in a nook adjustment to things which needed to be centered.. its a tiny bit off but I don't expect too many nook users (other than me using it