[LuvULongTime]

But regulators only have authority on their own turf, don't they? So 80% worldwide Android doesn't give the US regulators, for example, to shake a fist at Google if they only have 50%. I don't know about other regions.

A large part of the growth in the emerging markets is from OEMs that are not in the OHA anyway. That makes any regulatory justification even weaker.

I thought the European Union was investigating Google?

http://www.informationweek.com/mobil...a/d-id/1317770

Posted via CB10

[ADGrant]

I thought the European Union was investigating Google?

Google Breakup: Wrong Answer To EU Antitrust Concerns - InformationWeek

Posted via CB10

They are but its not about Android, its about search where they do almost have a monopoly.

[LuvULongTime]

They are but its not about Android, its about search where they do almost have a monopoly.

But Android only exists as a means for Google to continue its dominance into search via mobile. If the monopoly in search were ever dented somehow by regulators, it would have some impact on Android I would think.

[--TommesJay--]

Who talked solely about the US?
The US isn't the center of the world, when it comes down to smartphones. Yes, they surely lead with certain trends, but the rest of the world doesn't function in the same way as the US market.

Case in point, Android had a worldwide marketshare of over 80% in 2014 and basically all of the smartphone growth in terms of sales we have seen last year, and will continue to see this year, will solely be due to emerging markets.

I just read from Kantar World Panel that smartphone market penetration in western markets (US/Canada/Europe's Big 5) sits just at 58% as of the end of November 2014. There's still 42% feature phone users to convince apparently.

Posted via CB10

[TgeekB]

I just read from Kantar World Panel that smartphone market penetration in western markets (US/Canada/Europe's Big 5) sits just at 58% as of the end of November 2014. There's still 42% feature phone users to convince apparently.

Posted via CB10

Interesting. It seems like everyone has one, doesn't it?

[--TommesJay--]

I guess it might depend on the demographic

Posted via CB10

[ViBogdan]

Suuuure...and battery life isn't important either since we have now so many plugs everywhere, not to mention car chargers and portable chargers! VERY:sly: good ideea! :banghead:

[Plummerdc88]

Just want to take a second and thank everyone for there input on this thread. It's been quiet an interesting discussion to read through that's for sure.

Posted via CB10

[mnc76]

Xml for GUI technically. Java for the main but it's not all java in a android app.

Posted via CB10

Yes and no. While Android GUIs can be *specified* with XML, they are still implemented via the Android runtime with Java objects. OpenGL ES would be a better example.

E.g.: Below is some XML layout from one of my own Android apps:

<EditText
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:inputType="textPersonName"
android:ems="10"
android:id="@+id/editTextRegisterUsername"
android:layout_margin="5dp"
android:hint="* User Name"
android:enabled="true"
android:editable="true"
android:focusable="true"
android:focusableInTouchMode="true" />

This simply sets the arguments for the android.widget.EditText UI component Java object.

http://developer.android.com/referen.../EditText.html

In fact, you don't need to use XML at all. You can instantiate your UI purely programmatically if you want. The XML is simply used for convenience.

Posted from my awesome White Z30

[mnc76]

Xml for GUI technically. Java for the main but it's not all java in a android app.

Posted via CB10

I should point out that I was was responding to someone who said that essentially "the idea of using Java for cross-platform development hasn't worked out".

The point I was trying to make is that Java is the method that Android itself uses to allow the same APK to run across handsets with totally different hardware. E.g.: The same Android APK will run on a phone with an Intel chip and on a phone with an ARM chip, precisely because it's all Java under the hood (whether via an ART- or Dalvik-based Java runtime).

So even when you code your UI in XML, it is still a Java runtime behind the scenes making the actual UI run (because your XML is directly translated into Java code).

Posted from my awesome White Z30

[Dave Bourque]

I should point out that I was was responding to someone who said that essentially "the idea of using Java for cross-platform development hasn't worked out".

The point I was trying to make is that Java is the method that Android itself uses to allow the same APK to run across handsets with totally different hardware. E.g.: The same Android APK will run on a phone with an Intel chip and on a phone with an ARM chip, precisely because it's all Java under the hood (whether via an ART- or Dalvik-based Java runtime).

So even when you code your UI in XML, it is still a Java runtime behind the scenes making the actual UI run (because your XML is directly translated into Java code).

Posted from my awesome White Z30

Is there a performance hit when using Xml instead of instantiating directly with Java?

Posted via CB10

[mnc76]

Is there a performance hit when using Xml instead of instantiating directly with Java?

Posted via CB10

There should be no difference in performance.

Rule of thumb: Unless -- for certain technical reasons -- you need to programatically instantiate your UI, then using XML is preferred method as it provides a clean separation of your app logic from your UI.

However, even if you need to hand code your UI, then the best way is create your own custom UI classes by extending the stock widgets, e.g.:*

class com.bourque.DavesEditText
    extends android.widget.EditText {
     ...
}

You can then set things up in a way that will allow you to use your own custom widgets in your XML‎, such as

<com.bourque.DavesEditText
   ...
/>

and the Android runtime will instantiate and set the arguments to your own custom class.‎


Posted from my awesome White Z30

[ADGrant]

I should point out that I was was responding to someone who said that essentially "the idea of using Java for cross-platform development hasn't worked out".

The point I was trying to make is that Java is the method that Android itself uses to allow the same APK to run across handsets with totally different hardware. E.g.: The same Android APK will run on a phone with an Intel chip and on a phone with an ARM chip, precisely because it's all Java under the hood (whether via an ART- or Dalvik-based Java runtime).

So even when you code your UI in XML, it is still a Java runtime behind the scenes making the actual UI run (because your XML is directly translated into Java code).

Posted from my awesome White Z30

It should be pointed out that Windows Phone development also uses XML (they call it XMAL) and BB10 uses QML which is a similar idea.

As for cross platform, Android on different CPUs is a limited definition of cross platform, .NET is also cross platform by that measure. However, regular Java has been quite successful as a cross platform server technology.

[asherN]

It should be pointed out that Windows Phone development also uses XML (they call it XMAL) and BB10 uses QML which is a similar idea.

As for cross platform, Android on different CPUs is a limited definition of cross platform, .NET is also cross platform by that measure. However, regular Java has been quite successful as a cross platform server technology.

It's somewhat successful. The great promise of "code once, run many" eventually runs into the lowest common denominator. HTML5 will run into that as well. As a cross platform language, meaning the source can be compiled to many different architecture, JAVA has been successful. But it still requires platform specific coding. If for nothing else, the display resolution.

I guess it does depend on how we define "native app". As a former developer, I define "native" as designed, coded, compiled for a specific platform. Code that requires manipulation to make it run on a different platform. Regardless of the underlying programming language.

By those criterion, HTML5 won't really change a thing. Sure, it may be easier to recompile fr different platform. But they still need to be supported. And that, from a developer's perspective, is where BB falls off the face of the earth. Because BB's market share does not bring the revenue to justify the support.

[ADGrant]

It's somewhat successful. The great promise of "code once, run many" eventually runs into the lowest common denominator. HTML5 will run into that as well. As a cross platform language, meaning the source can be compiled to many different architecture, JAVA has been successful. But it still requires platform specific coding. If for nothing else, the display resolution.

I guess it does depend on how we define "native app". As a former developer, I define "native" as designed, coded, compiled for a specific platform. Code that requires manipulation to make it run on a different platform. Regardless of the underlying programming language.

By those criterion, HTML5 won't really change a thing. Sure, it may be easier to recompile fr different platform. But they still need to be supported. And that, from a developer's perspective, is where BB falls off the face of the earth. Because BB's market share does not bring the revenue to justify the support.

As a server cross platform language is quite successful. Display resolution is meaning less on the server. All the various flavors of Unix (including Linux and Mac OS-X look pretty much the same to server side Java and Windows has only file system differences.

As for HTML, that's often what server side Java is doing, serving up HTML or JSON to a web browser.

[asherN]

Display resolution is never meaningless. Especially on servers that will most likely be accessed through remote desktop. I have 4 different screen resolutions that I use to remote in my servers. The apps have to be able to handle that. And most of the time, they are oddball resolutions.

[ADGrant]

Display resolution is never meaningless. Especially on servers that will most likely be accessed through remote desktop. I have 4 different screen resolutions that I use to remote in my servers. The apps have to be able to handle that. And most of the time, they are oddball resolutions.

The servers we are talking about are server side applications (typically web servers), not desktop apps accessed via Remote Desktop