7 ms·

Android Studio 2.2

99 points by dvdyzag 10y ago

namelezz 10y ago
C++ Code Editing & CMake Support. Been waiting for this. Love that android studio is getting better.
- pjmlp 10y ago
  Yes, the experience is much better. Sadly the NDK APIs are still the same. Also be ware that at least during the beta period, the CMake build files had better support than Android.mk ones.
- AstralStorm 10y ago
  Still bit buggy in that changes to CMakeLists.txt or Android.mk do not refresh the targets and dependencies JSON.
eggy 10y ago
I've dabbled in Android dev, but have always lagged due to not really liking Java. Android Studio was a pleasant experience for me when I tried it this year, and now that C/C++ NDK support is better in this release I am going to give it another go. I almost feel like I should just go completely Android given the numbers of devices out there is overwhelming compared with Windows/iOS/OS X combined. I will keep up with my other PLs and things simply through osmosis. It's time to join the Borg!
- 2bitencryption 10y ago
  If you still don't like it, give Xamarin a shot (yeah I'm kind of pushing Xamarin here just because I couldn't believe how great it was).
  - eggy 10y ago
    See my replies above, but yes, I am a fan of F#, and I wish it were that easy, but I think simply learning Java (or Kotlin as pointed out above) might be the best way in the end. Google has made it very clear they are not working on an alternative from Java dev in Android.
- pjmlp 10y ago
  Just be aware that C and C++ are really meant for programming games, bringing code from other platforms or improve performance. Trying to write an app that isn't a game will make you enjoy the pleasures of JNI calls, given the APIs exposed to the NDK.
  - eggy 10y ago
    I know, since my first attempt was in Java to create a simple app. I know the NDK can be used to create OpenGLES guis, and access the sensors, but for a traditional app it's a lot of work. Syntax is a subjective thing; I just don't like Java. I was hoping Google was going to come up with something (other than Go), for Android. I have tried a lot of the work arounds, and simply put, Java is the way to do Android right, so I guess I need to get over it!
    - pjmlp 10y ago
      Yes, they have done a Reddit AMA a few months ago where they re-stated what they keep saying every time someone asks for an alternative at Google IO. Java is and will keep being the only main language on Android, with a little help from C++ when needed. https://www.reddit.com/r/androiddev/comments/4tm8i6/were_on_the_android_engineering_team_and_built/d5ilrui https://www.reddit.com/r/androiddev/comments/4tm8i6/were_on_... I am on a similar route, but I do like Java, what I dislike is their fork that prevents me to fully use Java™.
    - h1d 10y ago
      Would be a dream if they adopt Swift but then again, the history of blink/webkit fork does come to mind.
  - shadowmint 10y ago
    If no one used it, they wouldn't be adding better support for it. The NDK is pervasively used by many many applications; that's why it's getting more support. For some reason this seems unpopular with the android team, who seem to keep trying to avoid the issue when ever its raised at I/O...but hey, clearly at least someone is paying attention to what the statistics are showing. Sure, it's some extra hoops to jump though; but shared business logic that you can use on any code base on any platform; that's a really really compelling reason to use the NDK, or one of the stacks based on it (eg. Xamarin, react native). It's not just for some edge case. The biggest players in the field are doing this. I think it's misrepresentative to try to characterize this as 'just for games'...
- on_and_off 10y ago
  Have you tried Kotlin ? It does a really good job at fixing java's issues and since it outputs bytecode, you can write entire Android apps with it without writing a single line of java.
  - eggy 10y ago
    Not in a year, but it wasn't different enough to me - less verbose, but the same when I long for a Lisp or ML or Haskell for Android! Scala was a thought. And I am now looking at F# again with the recent OS works by MS and the Xamarin situation. As I wrote downstream, I just need to commit to Java (or Kotlin!) I think!
    - pjmlp 10y ago
      Check Xamarin documentation they have some Android F# samples.
      - eggy 10y ago
        I did, and they are great. I even have the Continuous App on my iPad Pro which is an F# development environment. It's incredible, but I am concerned about having to still drill down to the Android API, which means Java. I am thinking more and more against my wish, that biting the bullet and just going Java all the way is the key. Kotlin, Xtend, you still have to read Android SDK code in Java, correct? In terms of books, a friend bought me "Android 6 for Programmers: An App-Driven Approach (3rd Edition) (Deitel Developer Series)" to get me off the fence. I am going to work through it as much as I can to give Java a fair shake. I used to program in Java 5 for little side projects, but never mobile except for demo or tutorial apps years later. Is this a good Android/Java book, or should I stay on board with my interests and do an Android Game or Android AI book slant?
        pjmlp 10y ago
        I know Java since it was introduced in 1996 and had experience targeting J2ME, so learning Android wasn't that complicated to me. I own a few PacktPub books that I like, namely: https://www.packtpub.com/application-development/asynchronous-android-programming-second-edition https://www.packtpub.com/application-development/asynchronou... https://www.packtpub.com/application-development/android-application-development-cookbook-second-edition https://www.packtpub.com/application-development/android-app... https://www.packtpub.com/application-development/android-database-programming https://www.packtpub.com/application-development/android-dat... https://www.packtpub.com/application-development/android-ui-design https://www.packtpub.com/application-development/android-ui-... I don't know that book, so I cannot judge it, but it is important to try to use your interests as an idea for a possible app that you could use as learning process. If you stay on Java side than using something like LibGDX will help on the game programing ideas. Or if you prefer to jump into the "wonders" of NDK, then something like SDL or Cocos2D-x. For the Xamarin side, have you read the Petzold book? https://blogs.msdn.microsoft.com/microsoft_press/2016/03/31/free-ebook-creating-mobile-apps-with-xamarin-forms/ https://blogs.msdn.microsoft.com/microsoft_press/2016/03/31/... Regarding about using wanted programming languages, my experience with Turbo Pascal, Delphi, Oberon, Smalltalk and many other languages is that straying away from the true path of OS SDK supported languages usually ends in pain as the productivity gains get wasted battling interoperability issues, lack of tool support from the OS vendor and writing FFI bindings. So nowadays although I dabble in lot of languages, for production code I only use the OS SDK supported languages.
- shimfish 10y ago
  If your intention is to make money from selling apps, then don't let the market share fool you. It appears that it's rare for anyone to make more than 20% on Android compared to what they make on iOS.
kyriakos 10y ago
I tried many times to get into android development but everytime I get put off by the complexity of the api. The amount of digging in documentation you need to do in order to implement the simplest functionality scares me. Is anyone else feeling the same way? And does anyone know if it gets better with time or is it a constant struggle?
- blihp 10y ago
  I'm a grumpy geek who went down this path a few years ago and here's my $.02... It is a fairly complex, and in some cases downright convoluted, API for the functionality it offers and the tools are pretty crude. The good news is that it is logical and you can get used to it, the bad news is it is a constantly moving target (i.e. API bit rot can progress at an amazing rate on Android if you try to keep current with the SDK revisions. I've lost count of the number of policy changes and reversals on subsequent releases) Unless you have a professional need or burning curiosity, I probably wouldn't bother with it.
- omegaworks 10y ago
  2.2 introduces constraint layout support in the ide so you get drag and drop ui design like Xcode. Still have to wire things manually but libraries like butterknife are making that less painful. Theres a reason android developer avg salary is higher then iOS ;)
- alexkcd 10y ago
  The graphics stack in Android is badly designed. It is that way for historical reasons. Android used to do CPU-based blitting -- similar to other mobile platforms at the time: Symbian OS and Windows Pocket PC. Then the first iPhone launched & it became clear that GPU rendering was the way to go for mobile UI drawing. Rather than rebuild the graphics stack from the ground around GPU rendering, GPU support was tacked on to the existing graphics stack. Resulting in this franken-architecture: http://source.android.com/devices/graphics/architecture.html http://source.android.com/devices/graphics/architecture.html That guide has such gems as: "Once upon a time this was done with software blitting to a hardware framebuffer (e.g. /dev/graphics/fb0), but those days are long gone." "While this section uses SurfaceFlinger terminology, WindowManager uses the term window instead of layer…and uses layer to mean something else. (It can be argued that SurfaceFlinger should really be called LayerFlinger.)" "Some things that work with Surfaces want a SurfaceHolder, notably SurfaceView. The original idea was that Surface represented the raw compositor-managed buffer, while SurfaceHolder was managed by the app and kept track of higher-level information like the dimensions and format. The Java-language definition mirrors the underlying native implementation. It's arguably no longer useful to split it this way, but it has long been part of the public API." etc.
faitswulff 10y ago
I tried Android Studio around 2 years ago. Is the emulator any better? It used to bring my computer to its knees.
- robertmwm 10y ago
  Yes, use an Atom based image versus an Arm one, and it should be much faster.
- omegaworks 10y ago
  In Studio 2.0 it got much better. Just make sure you're using a recent gradle version in your project config (it'll prompt you if you open up an old project). Haven't had to use Genymotion since 2.0. Instant run is getting better w every release, I surprised the iOS dev last time I showed it to him.
- Larrikin 10y ago
  Running a real ARM emulator is still slow but for most things running an intel emulator with haxm will be fine. An actual device will be faster but the emulator will be suitable for simple test
  - hackerboos 10y ago
    You can use Genymotion is which pretty quick even on my Macbook Pro 2011 machine. Edit: Looks like it's not longer free.
- habosa 10y ago
  The Intel emulators these days are very fast, especially the ones you can create in Android Studio 2.0+. They are still resource hungry (RAM mostly) but they are now faster than developing on a physical device.
_RPM 10y ago
You need a pretty powerful machine to run Android Studio. It lags when I run it on my laptop with an i5 and 6 GB ram. I wonder if upgrading to a SSD will increase performance.
- voltagex_ 10y ago
  Yes, a good SSD will improve your performance compared to a spinning disk.
- habosa 10y ago
  I spend about 80% of my day in Android Studio and It's definitely resource hungry. On my brand new MBP 13" with 16GB RAM and an i7 processor it can still make the whole thing stutter when compiling a medium to large project. At work my desktop can handle it, but that thing has pretty unrealistic specs.
  - AstralStorm 10y ago
    It is not the IDE per se (300 MB RSS or so), but Java allocating some 2 GB heap per process, which also includes gradle daemon and compilers. This can easily eat a bunch of ram, making the OS swap. Seems OS X has extra bad policy of swapping.
    - Aaargh20318 10y ago
      I gave Android Studio 8GB of heap space to play with, and it still manages to run out. WTF.
- spacehunt 10y ago
  It wants about 2.5GB of RAM for itself, so you might be running out of RAM.
- biafra 10y ago
  It runs perfectly well on a current MacBook (12"). Which is the least performant Mac(Book) AFAIK.
- 10y ago
shadowmint 10y ago
Yay, no more 'modern makefile' nonsense, the native stuff is now officially supporting cmake in their build workflow! https://developer.android.com/studio/projects/add-native-code.html https://developer.android.com/studio/projects/add-native-cod... Like cmake or not, this is a really really great change for the whole workflow of using native plugins.
neelkadia 10y ago
yeah! There is too much thing yet to explore since I'm using this for some 7 years. Too many things untouched and amazed me.

Android Studio 2.2

99 points by dvdyzag 10y ago

namelezz 10y ago

C++ Code Editing & CMake Support. Been waiting for this. Love that android studio is getting better.

pjmlp 10y ago
Yes, the experience is much better. Sadly the NDK APIs are still the same. Also be ware that at least during the beta period, the CMake build files had better support than Android.mk ones.
AstralStorm 10y ago
Still bit buggy in that changes to CMakeLists.txt or Android.mk do not refresh the targets and dependencies JSON.

eggy 10y ago

I've dabbled in Android dev, but have always lagged due to not really liking Java. Android Studio was a pleasant experience for me when I tried it this year, and now that C/C++ NDK support is better in this release I am going to give it another go. I almost feel like I should just go completely Android given the numbers of devices out there is overwhelming compared with Windows/iOS/OS X combined. I will keep up with my other PLs and things simply through osmosis. It's time to join the Borg!

2bitencryption 10y ago
If you still don't like it, give Xamarin a shot (yeah I'm kind of pushing Xamarin here just because I couldn't believe how great it was).
- eggy 10y ago
  See my replies above, but yes, I am a fan of F#, and I wish it were that easy, but I think simply learning Java (or Kotlin as pointed out above) might be the best way in the end. Google has made it very clear they are not working on an alternative from Java dev in Android.
pjmlp 10y ago
Just be aware that C and C++ are really meant for programming games, bringing code from other platforms or improve performance. Trying to write an app that isn't a game will make you enjoy the pleasures of JNI calls, given the APIs exposed to the NDK.
- eggy 10y ago
  I know, since my first attempt was in Java to create a simple app. I know the NDK can be used to create OpenGLES guis, and access the sensors, but for a traditional app it's a lot of work. Syntax is a subjective thing; I just don't like Java. I was hoping Google was going to come up with something (other than Go), for Android. I have tried a lot of the work arounds, and simply put, Java is the way to do Android right, so I guess I need to get over it!
  - pjmlp 10y ago
    Yes, they have done a Reddit AMA a few months ago where they re-stated what they keep saying every time someone asks for an alternative at Google IO. Java is and will keep being the only main language on Android, with a little help from C++ when needed. https://www.reddit.com/r/androiddev/comments/4tm8i6/were_on_the_android_engineering_team_and_built/d5ilrui https://www.reddit.com/r/androiddev/comments/4tm8i6/were_on_... I am on a similar route, but I do like Java, what I dislike is their fork that prevents me to fully use Java™.
  - h1d 10y ago
    Would be a dream if they adopt Swift but then again, the history of blink/webkit fork does come to mind.
- shadowmint 10y ago
  If no one used it, they wouldn't be adding better support for it. The NDK is pervasively used by many many applications; that's why it's getting more support. For some reason this seems unpopular with the android team, who seem to keep trying to avoid the issue when ever its raised at I/O...but hey, clearly at least someone is paying attention to what the statistics are showing. Sure, it's some extra hoops to jump though; but shared business logic that you can use on any code base on any platform; that's a really really compelling reason to use the NDK, or one of the stacks based on it (eg. Xamarin, react native). It's not just for some edge case. The biggest players in the field are doing this. I think it's misrepresentative to try to characterize this as 'just for games'...
on_and_off 10y ago
Have you tried Kotlin ? It does a really good job at fixing java's issues and since it outputs bytecode, you can write entire Android apps with it without writing a single line of java.
- eggy 10y ago
  Not in a year, but it wasn't different enough to me - less verbose, but the same when I long for a Lisp or ML or Haskell for Android! Scala was a thought. And I am now looking at F# again with the recent OS works by MS and the Xamarin situation. As I wrote downstream, I just need to commit to Java (or Kotlin!) I think!
  - pjmlp 10y ago
    Check Xamarin documentation they have some Android F# samples.
    - eggy 10y ago
      I did, and they are great. I even have the Continuous App on my iPad Pro which is an F# development environment. It's incredible, but I am concerned about having to still drill down to the Android API, which means Java. I am thinking more and more against my wish, that biting the bullet and just going Java all the way is the key. Kotlin, Xtend, you still have to read Android SDK code in Java, correct? In terms of books, a friend bought me "Android 6 for Programmers: An App-Driven Approach (3rd Edition) (Deitel Developer Series)" to get me off the fence. I am going to work through it as much as I can to give Java a fair shake. I used to program in Java 5 for little side projects, but never mobile except for demo or tutorial apps years later. Is this a good Android/Java book, or should I stay on board with my interests and do an Android Game or Android AI book slant?
      - pjmlp 10y ago
        I know Java since it was introduced in 1996 and had experience targeting J2ME, so learning Android wasn't that complicated to me. I own a few PacktPub books that I like, namely: https://www.packtpub.com/application-development/asynchronous-android-programming-second-edition https://www.packtpub.com/application-development/asynchronou... https://www.packtpub.com/application-development/android-application-development-cookbook-second-edition https://www.packtpub.com/application-development/android-app... https://www.packtpub.com/application-development/android-database-programming https://www.packtpub.com/application-development/android-dat... https://www.packtpub.com/application-development/android-ui-design https://www.packtpub.com/application-development/android-ui-... I don't know that book, so I cannot judge it, but it is important to try to use your interests as an idea for a possible app that you could use as learning process. If you stay on Java side than using something like LibGDX will help on the game programing ideas. Or if you prefer to jump into the "wonders" of NDK, then something like SDL or Cocos2D-x. For the Xamarin side, have you read the Petzold book? https://blogs.msdn.microsoft.com/microsoft_press/2016/03/31/free-ebook-creating-mobile-apps-with-xamarin-forms/ https://blogs.msdn.microsoft.com/microsoft_press/2016/03/31/... Regarding about using wanted programming languages, my experience with Turbo Pascal, Delphi, Oberon, Smalltalk and many other languages is that straying away from the true path of OS SDK supported languages usually ends in pain as the productivity gains get wasted battling interoperability issues, lack of tool support from the OS vendor and writing FFI bindings. So nowadays although I dabble in lot of languages, for production code I only use the OS SDK supported languages.
shimfish 10y ago
If your intention is to make money from selling apps, then don't let the market share fool you. It appears that it's rare for anyone to make more than 20% on Android compared to what they make on iOS.

kyriakos 10y ago

I tried many times to get into android development but everytime I get put off by the complexity of the api. The amount of digging in documentation you need to do in order to implement the simplest functionality scares me. Is anyone else feeling the same way? And does anyone know if it gets better with time or is it a constant struggle?

blihp 10y ago
I'm a grumpy geek who went down this path a few years ago and here's my $.02... It is a fairly complex, and in some cases downright convoluted, API for the functionality it offers and the tools are pretty crude. The good news is that it is logical and you can get used to it, the bad news is it is a constantly moving target (i.e. API bit rot can progress at an amazing rate on Android if you try to keep current with the SDK revisions. I've lost count of the number of policy changes and reversals on subsequent releases) Unless you have a professional need or burning curiosity, I probably wouldn't bother with it.
omegaworks 10y ago
2.2 introduces constraint layout support in the ide so you get drag and drop ui design like Xcode. Still have to wire things manually but libraries like butterknife are making that less painful. Theres a reason android developer avg salary is higher then iOS ;)
alexkcd 10y ago
The graphics stack in Android is badly designed. It is that way for historical reasons. Android used to do CPU-based blitting -- similar to other mobile platforms at the time: Symbian OS and Windows Pocket PC. Then the first iPhone launched & it became clear that GPU rendering was the way to go for mobile UI drawing. Rather than rebuild the graphics stack from the ground around GPU rendering, GPU support was tacked on to the existing graphics stack. Resulting in this franken-architecture: http://source.android.com/devices/graphics/architecture.html http://source.android.com/devices/graphics/architecture.html That guide has such gems as: "Once upon a time this was done with software blitting to a hardware framebuffer (e.g. /dev/graphics/fb0), but those days are long gone." "While this section uses SurfaceFlinger terminology, WindowManager uses the term window instead of layer…and uses layer to mean something else. (It can be argued that SurfaceFlinger should really be called LayerFlinger.)" "Some things that work with Surfaces want a SurfaceHolder, notably SurfaceView. The original idea was that Surface represented the raw compositor-managed buffer, while SurfaceHolder was managed by the app and kept track of higher-level information like the dimensions and format. The Java-language definition mirrors the underlying native implementation. It's arguably no longer useful to split it this way, but it has long been part of the public API." etc.

faitswulff 10y ago

I tried Android Studio around 2 years ago. Is the emulator any better? It used to bring my computer to its knees.

robertmwm 10y ago
Yes, use an Atom based image versus an Arm one, and it should be much faster.
omegaworks 10y ago
In Studio 2.0 it got much better. Just make sure you're using a recent gradle version in your project config (it'll prompt you if you open up an old project). Haven't had to use Genymotion since 2.0. Instant run is getting better w every release, I surprised the iOS dev last time I showed it to him.
Larrikin 10y ago
Running a real ARM emulator is still slow but for most things running an intel emulator with haxm will be fine. An actual device will be faster but the emulator will be suitable for simple test
- hackerboos 10y ago
  You can use Genymotion is which pretty quick even on my Macbook Pro 2011 machine. Edit: Looks like it's not longer free.
habosa 10y ago
The Intel emulators these days are very fast, especially the ones you can create in Android Studio 2.0+. They are still resource hungry (RAM mostly) but they are now faster than developing on a physical device.

_RPM 10y ago

You need a pretty powerful machine to run Android Studio. It lags when I run it on my laptop with an i5 and 6 GB ram. I wonder if upgrading to a SSD will increase performance.

voltagex_ 10y ago
Yes, a good SSD will improve your performance compared to a spinning disk.
habosa 10y ago
I spend about 80% of my day in Android Studio and It's definitely resource hungry. On my brand new MBP 13" with 16GB RAM and an i7 processor it can still make the whole thing stutter when compiling a medium to large project. At work my desktop can handle it, but that thing has pretty unrealistic specs.
- AstralStorm 10y ago
  It is not the IDE per se (300 MB RSS or so), but Java allocating some 2 GB heap per process, which also includes gradle daemon and compilers. This can easily eat a bunch of ram, making the OS swap. Seems OS X has extra bad policy of swapping.
  - Aaargh20318 10y ago
    I gave Android Studio 8GB of heap space to play with, and it still manages to run out. WTF.
spacehunt 10y ago
It wants about 2.5GB of RAM for itself, so you might be running out of RAM.
biafra 10y ago
It runs perfectly well on a current MacBook (12"). Which is the least performant Mac(Book) AFAIK.
10y ago

shadowmint 10y ago

Yay, no more 'modern makefile' nonsense, the native stuff is now officially supporting cmake in their build workflow! https://developer.android.com/studio/projects/add-native-code.html https://developer.android.com/studio/projects/add-native-cod... Like cmake or not, this is a really really great change for the whole workflow of using native plugins.

neelkadia 10y ago

yeah! There is too much thing yet to explore since I'm using this for some 7 years. Too many things untouched and amazed me.