261–270 of 342 posts
Unless you are writing a Tier 1 application that needs every fancy do-hicky, I don't see the point of 100% native anymore. Use React Native, then if necessary have a devoted native developer for each platform to handle parts that absolutely have to be executed in native and provide a JavaScript API. If you are a big company with tons of money, sure, create duplicate teams to make the same app for each platform. But i…
I do not think writing Android apps is straight-forward and would not recommend it to new developers or engineers like the author who want to do other things like iOS. People's expectations for apps is only getting higher, and there are many, many things you need to understand in order to be a produce great Android apps. As an example, another commenter noted the Android platform engineers not being opinionated about…
I couldn't agree more. Android experience is hard-won. You have to 'discover' and develop an intuition for application architecture and how to use UI components effectively over time.
The upside is a well-architected Android application --using tools like MVP, dependency-injection, and functional-reactive programming-- will have the positive characteristics of a Service Oriented Architecture: encapsulation, statelessness, composability, loose-coupling. This may seem like overkill for an app, but it minimizes the effect of UI lifecycle issues novice and intermediate developers tend to complain about.
Architect a few Android applications in this way and you gain valuable experience composing abstract services together. A competency that is transferrable to backend services and other platforms.
We really need a native cross platform solution that doesn't involve either running a JavaScript VM (ReactNative, NativeScript), writing UI code for each OS (Xamarin), and doesn't rely on a WebView.
Xamarin Forms could fit the bill, but last time I checked it wasn't there yet.
What other option are there?
Earlier quoted context omitted.
I was surprised to learn that Android in 2016 doesn't even natively come with an equivalent of JavascriptCore. You have the pleasure of somehow getting V8 to run and then serialize/deserialize all your native objects manually in order to talk to it if you want javascript outside the browser. Really? From the company that is the most web native around, and even developed the most common browserless JS runtime (V8)? Go…
> I was surprised to learn that Android in 2016 doesn't even natively come with an equivalent of JavascriptCore. You have the pleasure of somehow getting V8 to run and then serialize/deserialize all your native objects manually in order to talk to it if you want javascript outside the browser. That's a little bit like saying that Chez Panisse doesn't even deliver sewage to your table, and that if you want to pour it…
Earlier quoted context omitted.
I think you just proved the point of the author. I haven't done any app development yet, but from how you describe it, it seems to be as hard to keep up with it as with the JS ecosystem. No wonder then that the author has trouble keeping up with two entirely distinct ecosystems, and chooses to focus on only one. (That said, I'm very glad that this is the top-voted comment, since it looks like a very valuable resource…
IMO it's really not (but I might be biased by experience) - the library churn is nowhere near the speed of the JavaScript world. All the libraries I mentioned are a few years old, battle tested and any larger conference or a resource (Android Weekly, Fragmented podcasts, etc.) will have numerous articles and talks on how to use them. The only exception is Kotlin as a language, which is pretty new and the tooling is s…
Mobile development in general is a pita. We really need a native cross platform solution that doesn't involve either running a JavaScript VM (ReactNative, NativeScript), writing UI code for each OS (Xamarin), and doesn't rely on a WebView. Xamarin Forms could fit the bill, but last time I checked it wasn't there yet. What other option are there?
I'd actually prefer if Apple and Google had their own development platforms so there are competitive driving forces to improve the platform. It will also accelerate experimentation with new tech where one platform can validate one tech so the other can adopt it quicker.
Then if you have a simple lightweight app you can use some form of cross-platform browsery JS app (about the only point where this makes sense).
I ended up choosing Android because I found more demand for Android developers in the market. I certainly understand some of the OP's frustration with Android development.
Earlier quoted context omitted.
You can open Android Studio, create a new project and "Go!". It'll work. Then you can add a single line of code to dependencies and you get even better APIs! I also have no idea why are you mixing the device updates into the developer tooling argument. New apps are (should be - and the tutorials tell you so) developed with API 19+ in mind which means that you'll have to work for quite a while to get any problems with…
>You can open Android Studio, create a new project and "Go!". It'll work I tried this after their 1.0 release and it crashed. Mileage varies from person to person
I agree it was abysmal at first - when it didn't crash, every new update would break compatibility and your projects wouldn't build anymore etc.
Right now it's pretty decent, considering, although I'm not a fan of Gradle either.
By the way, even though it's a fork of IntelliJ Idea, it's ultimately shaped by Google which has sort of a tradition of realeasing alpha-stage software into the world. Remember first releases of Chrome? I do; they crashed like crazy and lacked basic functionality such as printing.