4 ms·

> As previewed at Google I/O, Lollipop is our largest, most ambitious release on Android with over 5,000 new APIs for developers. As a developer not initiated

> As previewed at Google I/O, Lollipop is our largest, most ambitious release on Android with over 5,000 new APIs for developers. As a developer not initiated to the Android platform, the second half of this sentence is a very scary thing to read.

k-mcgrady 12y ago
iOS 8 included over 4,000. It's not really a big deal. There's stuff that's deprecated an replaced but won't be removed for several releases (and you'll get compiler warnings so you're aware), there's a tonne of stuff you'll never use, there are lots of API's for new features (iOS example: HealthKit), and then there are things which you'll come across from time to time that make your life a little easier.
on_and_off 12y ago
As an Android dev, Lollipop is indeed a big release but not a 'throw everything you have and start over' style change. Some things have been completely rewritten : Notifications have been using the same expanding API since version 1, it has been strongly revamped. The RemoteControlClient (which manages the lockscreen and is used for some other things like communication with Chromecast) was one of my least favorite parts of the Notification code, it is being phased out and replaced by a new, simpler (and hopefully more reliable) one. The ActionBar API (the bar of controls at the top of every android app) was initially based on the old menu API (from the time when we had menu buttons on Android). It was a very nice move to soften the menu button > actionbar transition but it is now adding unnecessary friction. Since the ActionBar has been redesigned, it was a very good opportunity to deprecate its API and replace it by a completely new one. ListView (the widget that handles lists) is one of the oldest Android widgets. It has been conceived in an era where displaying a static list was all you wanted. It is a central piece of almost every app UI and it is comically inadequate. It is going to be replaced by RecyclerView, which take into account modern requirements on lists (adding, removing items, handling gestures, ...). Many other changes are just additions. A better animation system, a tinting system for on screen elements, some new widgets, ... There are also some completely new APIs but many of these will only be used by a handful of developers (it is not every day that you need to convert the content of your screen to a PDF and print it).
- JamesSwift 12y ago
  RE: ListView Are they providing first-party horizontal lists (i.e. something to compete with UICollectionViews)? Still waiting for an official Gallery replacement... EDIT: Did the reasonable thing and actually looked it up myself [1,2]. Turns out they provide RecyclerView paired with a LinearlayoutManager to achieve arbitrary UI on top of a dataset. This is nearly identical to the iOS setup of UICollectionView with a UICollectionViewLayout (and LinearLayoutManager is == to UICollectionViewFlowLayout as far as I can tell). [1] - http://www.grokkingandroid.com/first-glance-androids-recyclerview/ [2] - https://developer.android.com/preview/material/ui-widgets.html
  - on_and_off 12y ago
    RecyclerView in fact only knows how to manage a pool of views that get recycled.. hence the name. Recycling is a very common approach to that problem on mobile, nothing new here, RecyclerView just specializes in recycling as best as possible. In order to use it, you need to specify a LayoutManager that will handle how elements are displayed on the screen. Google provides a linear one, and the community has already been working on Grid and staggered grid. Compared to ListView, RecyclerView does not make counterproductive assumptions on what it is going to do. ListView has been written in the Blackberry era. Its only goal was to display a static list of item. No animations, no operations on the items, no gestures. It is possible to implement some of these, but for all advanced operations you hit the assumptions that ListView made on how its items are displayed. In the end, you spend more time fighting the widget than building on top of it. RecyclerView shows a good separation of concerns. You want to implement gestures ? here you go, implement the RecyclerView.OnItemTouchListener interface and you are good to go. You want custom animations on addition/removal/replacement of an item ? No problem, just implement your own ItemAnimator. Many parts of the widget have been thought out in order to be customizable and get out of your way and let you build on top of it. Also, it is part of the support library. Google can update it as many times as necessary and make the changes available on all terminals since it is no longer a part of the platform. I am sure that RecyclerView has its own quirks and limitations. In fact in the dev preview while ListView only handle Headers and Footers very badly, RecyclerView does not handle them at all. However, it is a very strong foundation on top of which it will be possible to efficiently build an Android app without having to reinvent the wheel.

k-mcgrady 12y ago

iOS 8 included over 4,000. It's not really a big deal. There's stuff that's deprecated an replaced but won't be removed for several releases (and you'll get compiler warnings so you're aware), there's a tonne of stuff you'll never use, there are lots of API's for new features (iOS example: HealthKit), and then there are things which you'll come across from time to time that make your life a little easier.

on_and_off 12y ago

As an Android dev, Lollipop is indeed a big release but not a 'throw everything you have and start over' style change. Some things have been completely rewritten : Notifications have been using the same expanding API since version 1, it has been strongly revamped. The RemoteControlClient (which manages the lockscreen and is used for some other things like communication with Chromecast) was one of my least favorite parts of the Notification code, it is being phased out and replaced by a new, simpler (and hopefully more reliable) one. The ActionBar API (the bar of controls at the top of every android app) was initially based on the old menu API (from the time when we had menu buttons on Android). It was a very nice move to soften the menu button > actionbar transition but it is now adding unnecessary friction. Since the ActionBar has been redesigned, it was a very good opportunity to deprecate its API and replace it by a completely new one. ListView (the widget that handles lists) is one of the oldest Android widgets. It has been conceived in an era where displaying a static list was all you wanted. It is a central piece of almost every app UI and it is comically inadequate. It is going to be replaced by RecyclerView, which take into account modern requirements on lists (adding, removing items, handling gestures, ...). Many other changes are just additions. A better animation system, a tinting system for on screen elements, some new widgets, ... There are also some completely new APIs but many of these will only be used by a handful of developers (it is not every day that you need to convert the content of your screen to a PDF and print it).

JamesSwift 12y ago
RE: ListView Are they providing first-party horizontal lists (i.e. something to compete with UICollectionViews)? Still waiting for an official Gallery replacement... EDIT: Did the reasonable thing and actually looked it up myself [1,2]. Turns out they provide RecyclerView paired with a LinearlayoutManager to achieve arbitrary UI on top of a dataset. This is nearly identical to the iOS setup of UICollectionView with a UICollectionViewLayout (and LinearLayoutManager is == to UICollectionViewFlowLayout as far as I can tell). [1] - http://www.grokkingandroid.com/first-glance-androids-recyclerview/ [2] - https://developer.android.com/preview/material/ui-widgets.html
- on_and_off 12y ago
  RecyclerView in fact only knows how to manage a pool of views that get recycled.. hence the name. Recycling is a very common approach to that problem on mobile, nothing new here, RecyclerView just specializes in recycling as best as possible. In order to use it, you need to specify a LayoutManager that will handle how elements are displayed on the screen. Google provides a linear one, and the community has already been working on Grid and staggered grid. Compared to ListView, RecyclerView does not make counterproductive assumptions on what it is going to do. ListView has been written in the Blackberry era. Its only goal was to display a static list of item. No animations, no operations on the items, no gestures. It is possible to implement some of these, but for all advanced operations you hit the assumptions that ListView made on how its items are displayed. In the end, you spend more time fighting the widget than building on top of it. RecyclerView shows a good separation of concerns. You want to implement gestures ? here you go, implement the RecyclerView.OnItemTouchListener interface and you are good to go. You want custom animations on addition/removal/replacement of an item ? No problem, just implement your own ItemAnimator. Many parts of the widget have been thought out in order to be customizable and get out of your way and let you build on top of it. Also, it is part of the support library. Google can update it as many times as necessary and make the changes available on all terminals since it is no longer a part of the platform. I am sure that RecyclerView has its own quirks and limitations. In fact in the dev preview while ListView only handle Headers and Footers very badly, RecyclerView does not handle them at all. However, it is a very strong foundation on top of which it will be possible to efficiently build an Android app without having to reinvent the wheel.