3 ms·

I'm not sure Skia has a sufficiently stable API. And graphics are actually an OK case -- OpenGL ES is the key API here, and it's provided. What you want is sta

I'm not sure Skia has a sufficiently stable API. And graphics are actually an OK case -- OpenGL ES is the key API here, and it's provided. What you want is stable APIs for things that interact in fiddly ways with the rest of the system, so they're more easily managed at the OS level. Networking, shared databases. (Edit to add: localization) zlib is nice to have, but it's also really portable and lightweight. It would be easy for apps to bundle their own copies. Something like libcurl is a lot more awkward (what do you use for https? bundle your own SSL too!)

pjmlp 10y ago
Using a 2D library with canvas operations is not the same as rendering triangles. In any case that was just an example. Android has nothing like Objective-C++ or C++/CX for easy interoperability with the OS APIs.
- iainmerrick 10y ago
  Agreed. Even if you don't need a whole 2D library, it would be very useful to have a stable API for reading the system fonts, so apps don't have to ship their own.
- vetinari 10y ago
  Because Android's OS APIs are in Java for a reason. Yes, if you insist on using C++ with the OS APIs, you are pushing a square peg into a round hole, so enjoy JNI.
  - pjmlp 10y ago
    iOS and UWP show that is a way of having multiple languages share the OS APIs whithout the pain of JNI. Also, given that Google forked Java, they could have added something like CNI insteand of forcing everyone the JNI pain.
    - vetinari 10y ago
      iOS and UWP also were not designed with the intent to use single binary on any CPU architecture, independently from any appstore that could recompile for you. iOS also is not easy to use with any language, it assumes ability to link with a module written in ObjC. The pain of using UIKit with Python is comparable to using JNI.
      - pjmlp 10y ago
        > iOS and UWP also were not designed with the intent to use single binary on any CPU architecture, independently from any appstore that could recompile for you. It seems you never did UWP development. UWP was designed to be architecture independent since Windows Phone 8. Application's bytecode is uploaded to the store and gets compiled to each supported architecture using the so called "cloud compiler". iOS development has moved into that model with bitcode on iOS 9. Also there have been several C and C++ compilers across the years that could generate single binary on any CPU architecture. For example compilers for OS/400, TenDRA, PocketPC. > iOS also is not easy to use with any language, it assumes ability to link with a module written in ObjC. The pain of using UIKit with Python is comparable to using JNI. Python is not a platform language on iOS SDK, C and C++ are platform languages on iOS, Android and UWP SDKs. A good lesson in terms of productivity, is to only use SDK supported languages when writing production code any OS.
        vetinari 10y ago
        > Application's bytecode is uploaded to the store and gets compiled to each supported architecture using the so called "cloud compiler". That's why I wrote: independently from any appstore that could recompile for you. Google was and is under different constrain, that you refuse to acknowledge: everything, that puts an application onto the device, must be able to run locally at the development system. Amazon store, F-Droid, or whatever the Chinese or Russians are using cannot depend on Google Play Store to recompile for them. The result has to run not only on any combination of ARM/Neon/VFP3, but also on Intels, MIPSes or some future architecture, that someone somewhere used or will use in the Android device. Yes, they could use pNACL or LLVM bytecode, or whatever. They used a higher level one, dex. Their target was Java class hierarchy, they didn't want their developers to reinvent strings and collections all time. > Python is not a platform language on iOS SDK, C and C++ are platform languages on iOS, Android and UWP SDKs. C and C++ are not platform languages for Android. Literally, just read the first two paragraphs of Android NDK's "Getting Started" document. Using C/C++ is only for certain scenarios, that don't require the rich platform APIs. These are written in Java and if you are going to use non-JVM language, you are going to go through the same pain as if you were using Python with ObjC frameworks.

pjmlp 10y ago

Using a 2D library with canvas operations is not the same as rendering triangles. In any case that was just an example. Android has nothing like Objective-C++ or C++/CX for easy interoperability with the OS APIs.

iainmerrick 10y ago
Agreed. Even if you don't need a whole 2D library, it would be very useful to have a stable API for reading the system fonts, so apps don't have to ship their own.
vetinari 10y ago
Because Android's OS APIs are in Java for a reason. Yes, if you insist on using C++ with the OS APIs, you are pushing a square peg into a round hole, so enjoy JNI.
- pjmlp 10y ago
  iOS and UWP show that is a way of having multiple languages share the OS APIs whithout the pain of JNI. Also, given that Google forked Java, they could have added something like CNI insteand of forcing everyone the JNI pain.
  - vetinari 10y ago
    iOS and UWP also were not designed with the intent to use single binary on any CPU architecture, independently from any appstore that could recompile for you. iOS also is not easy to use with any language, it assumes ability to link with a module written in ObjC. The pain of using UIKit with Python is comparable to using JNI.
    - pjmlp 10y ago
      > iOS and UWP also were not designed with the intent to use single binary on any CPU architecture, independently from any appstore that could recompile for you. It seems you never did UWP development. UWP was designed to be architecture independent since Windows Phone 8. Application's bytecode is uploaded to the store and gets compiled to each supported architecture using the so called "cloud compiler". iOS development has moved into that model with bitcode on iOS 9. Also there have been several C and C++ compilers across the years that could generate single binary on any CPU architecture. For example compilers for OS/400, TenDRA, PocketPC. > iOS also is not easy to use with any language, it assumes ability to link with a module written in ObjC. The pain of using UIKit with Python is comparable to using JNI. Python is not a platform language on iOS SDK, C and C++ are platform languages on iOS, Android and UWP SDKs. A good lesson in terms of productivity, is to only use SDK supported languages when writing production code any OS.
      - vetinari 10y ago
        > Application's bytecode is uploaded to the store and gets compiled to each supported architecture using the so called "cloud compiler". That's why I wrote: independently from any appstore that could recompile for you. Google was and is under different constrain, that you refuse to acknowledge: everything, that puts an application onto the device, must be able to run locally at the development system. Amazon store, F-Droid, or whatever the Chinese or Russians are using cannot depend on Google Play Store to recompile for them. The result has to run not only on any combination of ARM/Neon/VFP3, but also on Intels, MIPSes or some future architecture, that someone somewhere used or will use in the Android device. Yes, they could use pNACL or LLVM bytecode, or whatever. They used a higher level one, dex. Their target was Java class hierarchy, they didn't want their developers to reinvent strings and collections all time. > Python is not a platform language on iOS SDK, C and C++ are platform languages on iOS, Android and UWP SDKs. C and C++ are not platform languages for Android. Literally, just read the first two paragraphs of Android NDK's "Getting Started" document. Using C/C++ is only for certain scenarios, that don't require the rich platform APIs. These are written in Java and if you are going to use non-JVM language, you are going to go through the same pain as if you were using Python with ObjC frameworks.