

Ask HN: What do you think about future of Android? - wsieroci

Hi,<p>Simple question: what do you think about future of Android? Any thoughts?<p>Best,
Wiktor
======
on_and_off
Android and iOS have won the first world, it's done. Some contenders
(Microsoft, Blackberry) try to grapple some market share, but unless Google or
Apple do something very stupid it seems doomed to be a very hard & slow
progression. Even with Microsoft throwing moneys at every major app makers,
the windows marketshare make it very hard for windows phone development to be
worth it.

If I had to make a gamble, I would say that Google is going to take over the
remaining 5 billion people too. Apple and emerging markets don't go together
at all. Microsoft & Firefox are targeting these markets but I feel that with
Android One & the changes made in 4.4 in order to have acceptable performances
on low end devices, Google has the formula to win. Nothing is done yet though.

Google has also decided to conquer other form factors. In order to do not
frighten its partners, these products are called Android (and it is indeed the
Android tech stack behind them). Google Wear is the first wearable device that
makes sense to me. That does not mean that it will be a big hit, but it is a
good start.

All these new hardware initiative (car, health, wearable, home, ...) from
Apple & Google are very impressive. They have many ideas in common and both
only work with mobile devices made by their company. There are probably at
least some technical reasons behind that move but it is still very
disappointing. I don't think that anybody in their right mind could be
entirely satisfied with a car or home automation system that dictate which
brand of smartphone you are going to be able to use.

As an Android dev, I am confident in Google's capacity to provide the tools I
need. Even though I don't think that Google made ALL the right choices
(lockscreen widgets still look like a very weird choice to me, they seem to be
disappearing with L though), my most critical needs were fulfilled with the
last i/o round of announcements with improved performances, first class design
('Holo' was really starting to look bleak compared to the other OSes) and the
replacement of the terrible ListView by RecyclerView.

There are a couple of parts where Android is still weak from a dev point of
view : -Even though Google is visually making many efforts in that area, the
company does not have the tool making expertise that Apple or Microsoft have.
Using IntelliJ was a very good move, the JetBrains guys know how to create an
IDE. Right now we are in a weird phase where Google is slowly giving the
finger to Eclipse and forcing us to migrate to Android Studio but it is still
a bit immature. Staying with Eclipse means not benefiting from many new
things, while migrating to AS means dealing with its bugs..

-Java is not as bad as its reputation can make you believe it is but there are real pain points (in the context of Android development at least, I don't really know the other sides of Java development to be honest). For example, Enums in java are syntactically awesome but for big codebases, they can contribute to bloating up your app if you use too much of them (each time you use an enum for the first time, all its members need to be instantiated and enum also generates some big methods). The alternative is to use bitfield flags or simple ints. It is better from a performance perspective, but it is absolutely ugly to use and does not offer any type safety. Some of Java weaknesses can be overcome with things like EventBus or RXJava but some are too deeply engrained in the language in order to be solved.

-Again, Google does not have enough tool-making expertise. I should be able to override the default widgets colors with a simple line in my layouts. This has just been added with the L release and I am not even sure that it is a back-compatible change, this should have been an API lvl 1 feature. There are many other examples where hundred of lines of code are necessary whereas it should be doable in one line with a good framework.

-Fragmentation is also not that bad but it is a reality you will have to work with. Crashlytics, bugsense and other crash reporting solutions are your best friends in order to detect and fix major fragmentation issues. Anecdotally, so far Samsung has been the biggest source of such issues for me.

-According to Android engineers, Java is here to stay. Since they don't communicate on their future plans, it is impossible to know whether they are working on alternatives or not but it would be welcome.

------
josephschmoe
Android needs two things:

1\. Real compatibility instead of compatibility libraries. Compatibility
libraries just serve to fragment the community and frustrate developers (try
to use Facebook integration fragments in a 4.0+ application if you don't
believe me).

2\. C#.

------
curtis17
Android needs to evolve away from Java. It needs a Swift - something richer,
more expressive, focused on modern 64bit platforms and above all open.

~~~
Someone1234
That post literally makes no sense.

Java is neither 32 nor 64 bit, it is bitness agnostic to a large degree (or at
least where it matters it is, datatypes aren't really a major advantage, and
most of the new CPU registers can be utilised in the JVM without the code
being aware or being recompiled).

You also say that they need something "richer" (whatever that means?), "more
expressive," (huh?), and "open" (even though the JVM on Android ("Dalvik") is
free and open source software).

Sorry but everything you said there is either confusing or wrong. You just
wanted to bring up Swift and seem to know absolutely nothing about
Java/JVC/Dalvik, except that it is "old" and therefore just assume it is
"bad."

I actually think C# is a better language than Java (at least in their current
iterations). However not for any of the reasons you cited, for real reasons
that actually make sense.

~~~
on_and_off
I agree, it was pretty much buzzword fest. Here : I think the Android
framework (Java + Android APIs + Android dev tools) should evolve towards
something less verbose. Let's say I want to add a new type of selector in my
ListView (for example for the active entry of the navigation drawer). I need
to declare it in attrs.xml, use it in my layout and also to write custom
versions of all the views that are going to use that selector in order to
override onCreateDrawableState and inject it there, not to mention all the
plumbing in different classes in order to get & set that state.. Ideally, I
should be able to simply declare that state in my layout selectors and simply
set it in the corresponding adapter.

There are many, many other examples where I need to modify many classes in
order to do something relatively common. There are also issues with some java
aspects like the enums that are syntactically very nice to use but not that
good for your performances. I also feel like a caveman each time I have to
write a bitfield. I should have a construct built into the language (or at
least the IDE, I don't really care which one) that gives me the flexibility
and type safety of enums while performing like a bitfield.

I don't know if getting rid of java is the answer here. I would not mind to,
but it would be very traumatic for the Android ecosystem. I hope that these
pain points will be fixed (I/O 2015 ? ^^). I don't think that Google will ever
use C#. However nice it is, it is controlled by Microsoft, which is probably
reason enough for Google to avoid it. There are other options though, Dart,
Rust, Go, an entirely new language, ...

------
petervandijck
Android will own the low end mobile space. iOS will own the high end.

Either the mobile OS wars are over and Android and iOS won (I think the most
likely scenario for the next 10 years), or there are major developments coming
up that we (I) can't foresee that will change this dynamic. But for now,
that's it.

