OTOH, software that has no bugs in need of fixing is usually not a realistic goal.
You can say it will probably never be done, or you update your definition of "done" to "it has no bugs stopping a release". Personally I prefer the latter.
From my experience the problem isn't the existence of bugs (like the existence of gravity), but the widespread occurrence of the cowboy programmer with very limited attention span.
Often there are tons of TODO comments left in the code (including TODO comment this class), unit tests are non-existent, a simple smoke test will cause a null pointer exception or not even deploy, or they committed schema migration SQL scripts but did not change the entities/data objects corresponding to those tables so the - now mandatory - new columns cannot even be FILLED by the app.
Stuff like that, that isn't DONE, it's deserving a punch in the face. OTOH, it may be symptomatic of our don't-blame culture that the consulting firm in question isn't fired on the spot or the much needed punch in the face isn't delivered. Those are days I wish we had US-American at-will employment and hire/fire culture.
It almost always means "bugs blocking release" in my experience. Usually the sentence I quoted is developer speak for "it's framed out, and the core functionality has been shown to work under this scheme," or "all of the known-to-be-risky stuff is done and all that's left is tedium," or perhaps some cross between the two.
It's not malicious. You could argue it's negligent, but I would only agree with that assessment if the Dev in question doesn't include the "it just has some bugs that need fixing" bit and is attempting to see what he/she can squeak by QA because he/she doesn't want to work on that thing anymore.
Otherwise it just reflects the difference in focus between writing code and building a product.
I hope Google gets us something official sooner rather than later. It's a little disheartening that I own a Chromebook Pixel and yet I can't use Google's own hardware to design or test Android apps without installing Eclipse on a sideloaded Linux chroot via Crouton.
If you're a developer you'll want a real Linux environment anyways so I would just go the crouton route. I've been really happy with my C720 and crouton running Ubuntu.
The fact that Google is starting to roll out the ability for Android apps to run as Chrome apps suggests that they are aware of the limitations of being "web only". It also stands to reason that if they're going to soon allow Android apps to run under ChromeOS, you should be able to develop them too, no?
To boot, the Pixel's relatively decent hardware, high-res display, and touchscreen just seem like it would be ideal for testing Android apps if it could be done natively.
I doubt it will ever be as simple as I would like. But I can dream.
There are no limitations of what you can do via a web browser. My company personally developed and delivered projects otherwise thought not possible in browser environments. With the help of extensions and solid JS and HTML, everything is possible. Of course super low level stuff are out of the picture but this is not normal users will be concerned about.
If they're going this roundabout way about bringing native apps to a browser-OS platform, I wonder they they couldn't just use the already native Android platform, which...already had the Chrome browser.
Only if you're making food intended to be usable by foodmakers? This is like expecting a father of 5 to only use a motorcycle because he works at a motorcycle factory.
Developing Android apps isn't an intended use case of the Chromebook. As such, Chrome OS devs can still "eat their own dogfood" without developing Android apps on a Chromebook.
I work for a navigation company. We deploy navigation software on 3rd party, purpose built hardware following model analagous to Chrome OS and the "Chromebook" moniker. Even though I use our devices in my car, would you say that I'm not "eating my own dog food" because I'm not writing software on the device in my car?
Is it a matter of features, speed, or convenience? Obviously, all of those can be overcome, be it as a fork of the official emulator or as a third-party emulator. For instance, this new Chrome extension must be the same thing under the hood: a Dalvik runtime, possibly an ARM->Intel recompiler for any NDK applications, etc.
I figured the only reason this wasn't done to mass effect already was because it wasn't in demand. But if it's so desirable, surely creating an actual emulator would be superior to hacking up web browser extensions and ostensibly playing cat-and-mouse with Google over this?
It's been a few years since I dared run the official emulator, and I used to have an underpowered computer for development, but last time it took about 10 minutes to boot Android and another 2-3 minutes to open an app.
I presume it's been improved since then and runs nicer on better hardware, but my first impulse is that speed is a huge concern in Android emulation. Convenience only matters if speed is solved, but then it becomes huge.
I don't know if anything changed within the past 2 years, but I had a high-end system 2.5 years ago where the emulator was just as slow as you describe it.
The official emulator is so slow it's a joke. Genymotion or Intel HAXM are a bit better but the whole process is clunky. Once Google introduces Android runtime to Chrome, developing for Android should become much easier.
I'm running Eclipse and the emulator on a 4 year old Mac Pro. Initial startup time for the emulator is about 20 seconds, but after that first hit has been absorbed, it generally takes about 8-10 seconds whenever I run a new build of the app I'm developing. (This is with HAXM [0] enabled. Still far too slow, so pretty much everybody does their development on actual Android devices, but far from the times reported in this thread.)
The Android emulator is terrible. It is one of those things that will speed up Android adoption if made better. iOS simulator is so much nicer to work with.
Hey Android developer here. I used to have the same issue - even on a fantastic machine the emulator would run very slowly, or not at all. This is now completely different
You no longer have to emulate ARM. You can run the native x86 image, using GPU acceleration, and the thing screams. I can get multiple high resolution emulators running in parallel without issue. I'm still used to debugging every single compile on an actual device having been through years of slow emulation, but let me tell you that the environment is quite different now. Genymotion is even better, but not by much with regards to performance.
The last time I worked on Android (which was about 6-12 months ago) I tried to get the x86 image working on my laptop, but it apparently requires an intel processor[1]. Do you happen to be aware of any speedups for AMD processors?
HAXM is enabled, I'm using an Intel image, and my system is Haswell with 8GN RAM? The official emulator still moves incredibly slowly. Genymotion just works.
Surely the Chrome extension is also an emulator, albeit a much faster one. Just seems like a large opportunity to create and sell the Parallels equivalent for Android, given the buzz this seems to be creating.
Edit: looks like that is done by Bluestacks and Genymotion. So I guess this is just about the novelty of the hack.
This is why I loved developing for Firefox OS. Their simulator is really just Gecko inside a smaller window and with simulated touch events. You could do some amazing things, such as live-inspect DOM on a connected device and treat it as if it were a local webpage. And now the WebIDE built into Firefox seems to be even more pleasant. I even used to sometimes test the app in my Firefox browser, without bothering to connect a device or fire up the simulator. It was super-speedy.
I'm so sad Firefox OS is probably never going to properly take off. I use Android and like it very much, but development for it is a literal nightmare.
Another vote for firefox OS here, I definitely think they're making a better effort than most in this space. The fact that firefox is targeting entry level devices in a serious way is another positive for me. I've been using a ZTE open as my primary device, and although the hardware is absolutely awful, I've managed to get by, mostly just because of a sentimental attachment to firefox.
I agree it's somewhat unlikely to be too successful, but I definitely think they're at least aiming in the right direction.
Last I checked the Android emulator was dog slow because it did CPU-level emulation of an ARM computer with qemu. You could get better performance (like iOS Simulator/OS X) by providing the runtime libraries with "native" implementations using the host's libraries.
My guess is that this is closer to a simulator. Just a Dalvik runtime and any necessary OS hooks, so it should be much faster than an ARM emulator or x86 Android build running in a virtual machine.
possibly an ARM->Intel recompiler
The NDK has an x86 target, so it would make sense to just rely on developers providing those in their APK.
Features - it is missing logging of any sort, so when an app crashes you don't know why. You can't use adb logcat nor presumably connect a debugger (I just use logcat most of the time anyway). e.g. an app I'm working on crashes when trying to use the "share" feature. this is probably to be expected, but without a log or anything it's tricky to know why. A game I made uses the NDK and despite having the x86 version of the library in the APK, it crashes on startup.
Speed - this is the killer feature! The emulator is useless (at least on Linux) as the native drivers cause it to hang IME, the startup time is too large, and when running an app is too slow to really judge its usage. You can use the emulator in a pinch, but better to test on devices. This means plugging them in and swapping devices (first world problems ;), which is a bit of a pain.
Convenience - the regular build-install-debug cycle is incorporated into the Android build system, whereas with this solution you have to faff about running your own scripts to execute chromeos-apk on the APK, then install by hand from the extensions screen. However you can debug right on the same PC without having to have a phone or tablet available.
So the main difference is speed and a bit of convenience. It is as fast as running the app on a real Android device, without having to have one handy. I can see why Google didn't release this for all apps yet, as there are a lot of places that it crashes out. But it's really cool that this works at all, and I'm sure it'll only get better.
Slight update, if you set `"enableAdb" : true` in the app's manifest.json, then you can connect adb and view the log. This makes the whole thing miles better than the emulator.
An emulator is a dev tool that recreates the whole OS.
It is very useful for devs since that way you can test your app on multiple architectures or Android versions.
You can even use it to run automatic tests after each commits (or each day) in order to control your app quality.
On the other hand, what we have in ChromeOS (and soon Chrome) is a reproduction of the Dalvik/ART runtime. As a runtime, its only job is to allow Android apps to run.
It probably was an huge amount of work for the Chrome team (apparently, they have been working on it for quite some time but now that it is here, it means that with it installed you can run Android apps on your desktop computer.
so, it is both a matter of features, speed and convenience.
I am an Android dev. In the startup I work for, we have mobile apps (Android, iOS and even Windows Phone), a website and are even working on desktop versions of our product.
I don't know what this will mean for us though. Sure, we can use this new runtime to make our Android app run on the desktop but it has been thought out for mobile UX so a huge amount of work would be necessary to make it work nicely with the mouse+keyboard combo.
It is very nice that we now have that option though, especially with Material Design looming in the corner.
What is on debian today that you can't get on or don't like about OSX? I ask this as a former Linux die hard. What am I missing back in the Linux world these days?
Also, One Note is killer isn't it? It is so much nicer than Evernote. I've loved One Note ever since the first time it shipped with Office. It's so great to see Microsoft porting their better apps to other platforms.
I can't (easily and reliably) get OS X to run on my non-Mac computer while Debian runs like a champion, this is what's missing from OS X :) Otherwise I would like to try it seriously as my main OS if I get a chance in the future. Heck, I even used Windows 7/8 for a few years and even they get good enough after installing Cygwin, so I can't think of any showstoppers that would make me dislike OS X. (Well, lack of the vast apt repository may be a problem, but they say very good things about homebrew and MacPorts, so this wouldn't be an issue I guess.)
I was a heavy OneNote user in Windows and accumulated a lot of stuff in it, so after coming back to Debian, I desperately tried running it in Wine and also tried the Web version but unfortunately they didn't cut it. Currently I use CherryTree[0] and it gets the job done but it's very far away from the OneNote experience.
You're welcome. I'll try it when I get a chance. It's nice to hear Microsoft had done a good job with OneNote in iOS instead of getting away with a half baked port.
I use and love it also :) But it doesn't satisfy all my note taking needs so I use it mostly for sharing and storing short-lived texts that I need to access from my phone.
I heard Simplenote developers was also thinking about a native & offical Linux client. I can't wait to try it out.
So, now we can write apps in Angular that run on the web and compile to Java so that we can install them to Android, running on ChromeOS, running on OSX.
Brilliant.
Edit: Perhaps the punny nature of this is deserving of downvotes, but the statement above is the actual use case I presented to a co-developer, discussing how this project could be of use to our app, which was built with Ionic.
FWIW, there's value in it (the app, not necessarily this post) even if it means having to unplug fewer devices to swap them out with different devices to test.
I hope Google could really carry this project as far as possible. The next several major issues would be polishing up the platform, eliminating the bugs, unifying the android and chromebook development interface. Think of one day when android developers could actually design apps for the desktop. How cool would that be?
We worked with the ARC team at Vine as a launch partner, there were 0 modifications that we had to do to get it working on ARC. The only difference was that the "bugs" we had to fix were all reproducible on Nexus devices as well BUT the threading model had to be more strict on ARC in terms accessing system resources.
96 comments
[ 3.6 ms ] story [ 192 ms ] threadFrom the README:
> Soundcloud - Works, crashes when playing sound
Funny definition of 'works'.
"It's done; it just has some bugs that need fixing."
To be fair, I've said this sentence myself in earnest several times.
You can say it will probably never be done, or you update your definition of "done" to "it has no bugs stopping a release". Personally I prefer the latter.
Often there are tons of TODO comments left in the code (including TODO comment this class), unit tests are non-existent, a simple smoke test will cause a null pointer exception or not even deploy, or they committed schema migration SQL scripts but did not change the entities/data objects corresponding to those tables so the - now mandatory - new columns cannot even be FILLED by the app.
Stuff like that, that isn't DONE, it's deserving a punch in the face. OTOH, it may be symptomatic of our don't-blame culture that the consulting firm in question isn't fired on the spot or the much needed punch in the face isn't delivered. Those are days I wish we had US-American at-will employment and hire/fire culture.
It's not malicious. You could argue it's negligent, but I would only agree with that assessment if the Dev in question doesn't include the "it just has some bugs that need fixing" bit and is attempting to see what he/she can squeak by QA because he/she doesn't want to work on that thing anymore.
Otherwise it just reflects the difference in focus between writing code and building a product.
That's like a winedb entry that says "game works" followed by "crashes after intro video"!
I hope Google gets us something official sooner rather than later. It's a little disheartening that I own a Chromebook Pixel and yet I can't use Google's own hardware to design or test Android apps without installing Eclipse on a sideloaded Linux chroot via Crouton.
* Xubuntu https://www.distroshare.com/distros/get/14/
* Ubuntu https://www.distroshare.com/distros/get/12/
To boot, the Pixel's relatively decent hardware, high-res display, and touchscreen just seem like it would be ideal for testing Android apps if it could be done natively.
I doubt it will ever be as simple as I would like. But I can dream.
Why? Can you develop Android apps on your phone?
https://play.google.com/store/apps/details?id=com.aide.ui&hl...
...so what you're saying is there are limitations around what you can do with a browser.
So when do we see Crysis or HPC in HTML 5?
"Introducing the Chromebook Pixel A laptop that brings together the best in hardware, software, and design."
"HP Chromebook 11. Made with Google. Everything you need in one laptop. For $279."
"A new type of computer designed to help you get things done faster and easier."
One click from there is the features page[2]:
"Meet Chromebook A new type of computer with everything built-in. For everyone. Starting at $199."
"Gets everyday things done Your favorite apps are built-in and one click away. Find thousands more in the Chrome Web Store."
"Meet the family Chromebooks are fast, easy to use, and great for everyone in your life who could use a computer."
Laptop. Computer. Everything built in. Thousands of apps in the Chrome Web Store. "For everyone in your life who could use a computer."
Google is absolutely, positively claiming these are computers for everyone.
1) https://www.google.com/chrome/devices/index.html
2) https://www.google.com/chrome/devices/features/
I work for a navigation company. We deploy navigation software on 3rd party, purpose built hardware following model analagous to Chrome OS and the "Chromebook" moniker. Even though I use our devices in my car, would you say that I'm not "eating my own dog food" because I'm not writing software on the device in my car?
Is it a matter of features, speed, or convenience? Obviously, all of those can be overcome, be it as a fork of the official emulator or as a third-party emulator. For instance, this new Chrome extension must be the same thing under the hood: a Dalvik runtime, possibly an ARM->Intel recompiler for any NDK applications, etc.
I figured the only reason this wasn't done to mass effect already was because it wasn't in demand. But if it's so desirable, surely creating an actual emulator would be superior to hacking up web browser extensions and ostensibly playing cat-and-mouse with Google over this?
I presume it's been improved since then and runs nicer on better hardware, but my first impulse is that speed is a huge concern in Android emulation. Convenience only matters if speed is solved, but then it becomes huge.
Dev system needs at lease able to run eclipse or android studio + emulator + adb at the same time.
Admittedly there are few on the market.
Just timed starting up a fresh instance, unlocking it and starting Maps.
This is starting from when I clicked launch in AVD manager on a mid-range laptop from 2011
1:25 emulator showed up
1:53 until lock screen
1:61 until maps loaded
[0] https://software.intel.com/en-us/android/articles/intel-hard...
You no longer have to emulate ARM. You can run the native x86 image, using GPU acceleration, and the thing screams. I can get multiple high resolution emulators running in parallel without issue. I'm still used to debugging every single compile on an actual device having been through years of slow emulation, but let me tell you that the environment is quite different now. Genymotion is even better, but not by much with regards to performance.
[1]: https://developer.android.com/tools/devices/emulator.html#vm...
Surely by "Intel" they mean "x86-compatible"? Many AMD cpus have the necessary VT-x, you shouldn't have any trouble here.
When they say Intel they mean Intel unfortunately.
Edit: looks like that is done by Bluestacks and Genymotion. So I guess this is just about the novelty of the hack.
I'm so sad Firefox OS is probably never going to properly take off. I use Android and like it very much, but development for it is a literal nightmare.
I agree it's somewhat unlikely to be too successful, but I definitely think they're at least aiming in the right direction.
Features - it is missing logging of any sort, so when an app crashes you don't know why. You can't use adb logcat nor presumably connect a debugger (I just use logcat most of the time anyway). e.g. an app I'm working on crashes when trying to use the "share" feature. this is probably to be expected, but without a log or anything it's tricky to know why. A game I made uses the NDK and despite having the x86 version of the library in the APK, it crashes on startup.
Speed - this is the killer feature! The emulator is useless (at least on Linux) as the native drivers cause it to hang IME, the startup time is too large, and when running an app is too slow to really judge its usage. You can use the emulator in a pinch, but better to test on devices. This means plugging them in and swapping devices (first world problems ;), which is a bit of a pain.
Convenience - the regular build-install-debug cycle is incorporated into the Android build system, whereas with this solution you have to faff about running your own scripts to execute chromeos-apk on the APK, then install by hand from the extensions screen. However you can debug right on the same PC without having to have a phone or tablet available.
So the main difference is speed and a bit of convenience. It is as fast as running the app on a real Android device, without having to have one handy. I can see why Google didn't release this for all apps yet, as there are a lot of places that it crashes out. But it's really cool that this works at all, and I'm sure it'll only get better.
On the other hand, what we have in ChromeOS (and soon Chrome) is a reproduction of the Dalvik/ART runtime. As a runtime, its only job is to allow Android apps to run.
It probably was an huge amount of work for the Chrome team (apparently, they have been working on it for quite some time but now that it is here, it means that with it installed you can run Android apps on your desktop computer.
so, it is both a matter of features, speed and convenience. I am an Android dev. In the startup I work for, we have mobile apps (Android, iOS and even Windows Phone), a website and are even working on desktop versions of our product. I don't know what this will mean for us though. Sure, we can use this new runtime to make our Android app run on the desktop but it has been thought out for mobile UX so a huge amount of work would be necessary to make it work nicely with the mouse+keyboard combo. It is very nice that we now have that option though, especially with Material Design looming in the corner.
What is on debian today that you can't get on or don't like about OSX? I ask this as a former Linux die hard. What am I missing back in the Linux world these days?
Also, One Note is killer isn't it? It is so much nicer than Evernote. I've loved One Note ever since the first time it shipped with Office. It's so great to see Microsoft porting their better apps to other platforms.
Freedom.
I was a heavy OneNote user in Windows and accumulated a lot of stuff in it, so after coming back to Debian, I desperately tried running it in Wine and also tried the Web version but unfortunately they didn't cut it. Currently I use CherryTree[0] and it gets the job done but it's very far away from the OneNote experience.
[0] http://www.giuspen.com/cherrytree/
I heard Simplenote developers was also thinking about a native & offical Linux client. I can't wait to try it out.
The ability to use any hardware other than a Mac, presumably.
Brilliant.
Edit: Perhaps the punny nature of this is deserving of downvotes, but the statement above is the actual use case I presented to a co-developer, discussing how this project could be of use to our app, which was built with Ionic.
FWIW, there's value in it (the app, not necessarily this post) even if it means having to unplug fewer devices to swap them out with different devices to test.
I hope Google could really carry this project as far as possible. The next several major issues would be polishing up the platform, eliminating the bugs, unifying the android and chromebook development interface. Think of one day when android developers could actually design apps for the desktop. How cool would that be?
That's when Microsoft should really get worried.
Dam but it looks full of promise i hope one day it will work well ...
[1] http://commondatastorage.googleapis.com/chromium-browser-con...