ubuntu-phone team mailing list archive

[Josh Leverette <coder543@xxxxxxxxx>]

If you need further proof that this is a bad idea, then look at this blog
post:
http://crackberry.com/build-or-port-blackberry-developers-thoughts-about-android-app-support-blackberry

The screenshots really drive home the point. Also worth noting is that
somewhere under 70% of Android apps were supported even with this
compatibility layer. Even WINE has better compatibility than that in my
experience. Tell me what Android apps are *so* important to you that you
would want to ruin any chances of success that Ubuntu touch has by adding
in a mediocrity layer for developers?


On Fri, Jun 21, 2013 at 8:16 AM, leon lee <llrraa@xxxxxx> wrote:

> To merge two systems together, we need to know more about the ARCH of
> both, or we would be lost. I think you must be very familiar with the ARCH
> of touch, why not introduce it to us. Or show us where to find the
> infomation.
>
>
> ------------------ Original ------------------
> *From: * "Thomas Vo "<thomas.voss@xxxxxxxxxxxxx>;
> *Date: * Fri, Jun 21, 2013 09:00 PM
> *To: * "leon lee"<llrraa@xxxxxx>; **
> *Cc: * "ubuntu-phone"<ubuntu-phone@xxxxxxxxxxxxxxxxxxx>; **
> *Subject: * Re: [Ubuntu-phone] Qt5 and touch performance issue
>
>
>
>
> On Fri, Jun 21, 2013 at 2:52 PM, leon lee <llrraa@xxxxxx> wrote:
>
>> activity manager: like the name says, manage the activity, and also some
>> memory management.
>> When an activity starts, the activity manager would request zygote( the
>> mother of almost everything in android ) to fork a thread, and then the
>> activity manager manages this activity/thread.
>> When the activity stops, the thread is not killed. So next time when the
>> same activty is being started, the thread can be used for it at once, so to
>> save time. But when the memory is not enough, the thread with no activity
>> running would be killed first. This is the major part of memory management.
>> So you can say activity manager just manages the thread, and this should
>> be the basic module of touch.
>> For android 2.3, the code locates in
>> framework/base/services/java/com/android/server/am/, in case you want to
>> look into it.
>>
>>
> Content provider: from comment of ContentProvider.java:
>> Content providers are one of the primary building blocks of Android
>> applications, providing content to applications. They encapsulate data and
>> provide it to applications through the single ContentResolver interface. A
>> content provider is only required if you need to share data between
>> multiple applications. For example, the contacts data is used by multiple
>> applications and must be stored in a content provider. If you don't need to
>> share data amongst multiple applications you can use a database directly
>> via android.database.sqlite.SQLiteDatabase.
>> For more information, read Content Providers.
>> When a request is made via a ContentResolver the system inspects the
>> authority of the given URI and passes the request to the content provider
>> registered with the authority. The content provider can interpret the rest
>> of the URI however it wants. The UriMatcher class is helpful for parsing
>> URIs.
>> leon: I think Content provider is just the abstract class for data
>> sharing between multiple applications, data like contacts.
>>
>> For android 2.3, the code locates in
>> frameworks/base/core/java/android/content/, in case you want to look into
>> it.
>> also:
>> http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.3.4_r1/android/content/ContentProvider.java
>>
>>
> Thanks for the summary, I'm aware of the purpose and the internals of both
> ActivityManager and ContentProvider.
>
> Again, the level of detail we would require to get started is much higher
> and I do not think that the approach of picking two components at random
> and summarizing their \brief-documentation helps.
>
> Thanks,
>
> Thomas
>
>
>> ------------------ Original ------------------
>> *From: * "Thomas Vo "<thomas.voss@xxxxxxxxxxxxx>;
>> *Date: * Fri, Jun 21, 2013 07:17 PM
>> *To: * "leon lee"<llrraa@xxxxxx>; **
>> *Cc: * "ubuntu-phone"<ubuntu-phone@xxxxxxxxxxxxxxxxxxx>; **
>> *Subject: * Re: [Ubuntu-phone] Qt5 and touch performance issue
>>
>>
>>
>>
>> On Fri, Jun 21, 2013 at 1:03 PM, leon lee <llrraa@xxxxxx> wrote:
>>
>>> If we look at the ARCH of android, I think we need change the framwork,
>>> expecially activity manager, window manager, content providers, view
>>> system. If touch has such an ARCH chart, it would be easier to know what to
>>> do from the ARCH aspect.
>>>
>>
>> We don't have an activity manager, content providers or a view system
>> (the latter is a toolkit btw, so roughly the equivalent of Qt/QML &
>> HTML5/JS). A window manager is there of course, but not in the sense that
>> android exposes it. As much as I'm a fan of block diagrams, I'm afraid that
>> we need to dive a lot deeper into the details of the Android SDK to really
>> map individual components.
>>
>> Again: Help with that is greatly appreciated :-)
>>
>> Thanks,
>>
>> Thomas
>>
>>>
>>>
>>> ------------------ Original ------------------
>>> *From: * "Thomas Vo "<thomas.voss@xxxxxxxxxxxxx>;
>>> *Date: * Thu, Jun 20, 2013 11:18 PM
>>> *To: * "leon lee"<llrraa@xxxxxx>; **
>>> *Cc: * "ubuntu-phone"<ubuntu-phone@xxxxxxxxxxxxxxxxxxx>; **
>>> *Subject: * Re: [Ubuntu-phone] Qt5 and touch performance issue
>>>
>>> On Thu, Jun 20, 2013 at 4:53 PM, leon lee <llrraa@xxxxxx> wrote:
>>> > When I say make android dvm available on touch, I mean keep the
>>> performance
>>> > of touch, and make dvm adapted to touch. It means that we will change
>>> the
>>> > framwork of android. this would be much helpful for touch's marketing.
>>> > Don't worry about the "good enough" issue. The competition of app
>>> companies
>>> > is tense. If touch's app performs better, and some of the companies
>>> would
>>> > make use of it, and the others would have to follow up.
>>> > Btw, why do I keep making new thread in the mailist?
>>> >
>>>
>>> Let us assume Ubuntu Touch would want to support Android apps:
>>>
>>> Then we would not only need to pull in Dalvik (or an equivalent that
>>> might need a lot of optimization to fly on mobile cpus) in its
>>> functionality as an interpreter, but also walk through the complete
>>> Android SDK & its class library and map all platform-specific
>>> functionality down to the Ubuntu Touch platform. In essence, we would
>>> need to re-implement huge portions of the SDK and maintain it over
>>> time, as both the Android SDK and the Ubuntu Touch platform evolves.
>>> While this is certainly doable from a technical perspective, I think
>>> that two major issues need to be considered here first:
>>>
>>> (1.) There will certainly be areas in the Android SDK that we either
>>> don't want or simply can't map to Ubuntu Touch.
>>> (2.) The sheer size of the overall Android SDK.
>>>
>>> To address (1.) and (2.) we could start over with inspecting the
>>> Android SDK and the class library and check for individual
>>> namespaces/classes if there is an equivalent on Ubuntu Touch that they
>>> map to. If so, it would be quite interesting to know how prominent the
>>> component is for app developers in order to be able to prioritize the
>>> porting effort.
>>>
>>> Any help with this preliminary evaluation would be greatly appreciated :)
>>>
>>> Thanks,
>>>
>>> Thomas
>>>
>>> > ------------------ Original ------------------
>>> > From: "Josh Leverette"<coder543@xxxxxxxxx>;
>>> > Date: Thu, Jun 20, 2013 09:58 PM
>>> > To: "leon lee"<llrraa@xxxxxx>;
>>> > Cc: "ubuntu-phone"<ubuntu-phone@xxxxxxxxxxxxxxxxxxx>;
>>> > Subject: Re: [Ubuntu-phone]Qt5 and touch performance issue
>>> >
>>> > If you ever want the system to perform smoothly, then we must
>>> absolutely
>>> > never officially support running Android apps on Ubuntu. Additionally,
>>> it
>>> > would be a death sentence for Ubuntu touch. Adding Android app support
>>> would
>>> > crush any chance of Ubuntu ever having good apps. When companies see
>>> that
>>> > their Android app on Ubuntu is "good enough", they will never bother
>>> to make
>>> > an "excellent" version for Ubuntu. But when the only option is
>>> excellence,
>>> > mediocrity is not encouraged. Ubuntu will suffer at first because of
>>> this
>>> > decision, but it will be stronger in the long run as a result. "Delayed
>>> > gratification" is another way to describe it.
>>> >
>>> > I agree that making the system smooth is very important, but they are
>>> > writing a new display server for Ubuntu touch. Until that is finished,
>>> most
>>> > time spent optimizing performance would be wasted. We must wait.
>>> >
>>> >
>>> > On Thu, Jun 20, 2013 at 8:30 AM, leon lee <llrraa@xxxxxx> wrote:
>>> >>
>>> >> I still think the most important thing right now for touch is to have
>>> a
>>> >> reliable smoth system. For app, in the long term, we should make
>>> android dvm
>>> >> available on touch. So we can make use of all the android apps.
>>> >>
>>> >>
>>> >> ------------------ Original ------------------
>>> >> From: "Josh Leverette"<coder543@xxxxxxxxx>;
>>> >> Date: Thu, Jun 20, 2013 09:45 AM
>>> >> To: "leon lee"<llrraa@xxxxxx>;
>>> >> Cc: "ubuntu-phone"<ubuntu-phone@xxxxxxxxxxxxxxxxxxx>;
>>> >> Subject: Re: [Ubuntu-phone]Qt5 and touch performance issue
>>> >>
>>> >> For now, features are most important. I hope that they will start
>>> fixing
>>> >> performance soon. The design is good. Performance should not be an
>>> issue. If
>>> >> it is, that would make me sad. I am confident that they will fix it.
>>> >>
>>> >> Sincerely,
>>> >> Josh
>>> >>
>>> >> On Jun 19, 2013 8:07 PM, "leon lee" <llrraa@xxxxxx> wrote:
>>> >>>
>>> >>> This would be the major issur of touch. Can we discuss more details?
>>> >>> Let's if there's something we can do.
>>> >>>
>>> >>>
>>> >>> ------------------ Original ------------------
>>> >>> From: "Josh Leverette"<coder543@xxxxxxxxx>;
>>> >>> Date: Thu, Jun 20, 2013 03:05 AM
>>> >>> To: "leon lee"<llrraa@xxxxxx>;
>>> >>> Cc: "ubuntu-phone"<ubuntu-phone@xxxxxxxxxxxxxxxxxxx>;
>>> >>> Subject: Re: [Ubuntu-phone] how do you feel about touch
>>> >>>
>>> >>> It is based on Qt5, and Qt5 makes heavy use of GPU acceleration.
>>> Right
>>> >>> now there are a few performance issues, but I expect that Ubuntu
>>> will run
>>> >>> very smoothly once finished.
>>> >>>
>>> >>>
>>> >>> On Wed, Jun 19, 2013 at 8:54 AM, leon <llrraa@xxxxxx> wrote:
>>> >>>>
>>> >>>> After know the ARCH of android, which is using java as the
>>> framework, I
>>> >>>> feel a little disappointed. That means that with the hardware,
>>> android won't
>>> >>>> be as smooth as IOS, which is on the native framework.
>>> >>>> From that day, I'm looking forward to a better android. At first,
>>> I'm
>>> >>>> thinking about the combination of android and meego, just like what
>>> touch
>>> >>>> does today. Luckly, I found touch, so I don't need to move a long
>>> way to get
>>> >>>> my goal.
>>> >>>> Since I don't have a working touch handset, I hope people using
>>> touch
>>> >>>> can share your feeling with me. Would it be faster and smoother
>>> with touch
>>> >>>> than android?
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Mailing list: https://launchpad.net/~ubuntu-phone
>>> >>>> Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>>> >>>> Unsubscribe : https://launchpad.net/~ubuntu-phone
>>> >>>> More help : https://help.launchpad.net/ListHelp
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Sincerely,
>>> >>> Josh
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Sincerely,
>>> > Josh
>>> >
>>> > --
>>> > Mailing list: https://launchpad.net/~ubuntu-phone
>>> > Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>>> > Unsubscribe : https://launchpad.net/~ubuntu-phone
>>> > More help : https://help.launchpad.net/ListHelp
>>> >
>>>
>>
>>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Sincerely,
    Josh

Attachment: EB97681A@5D3FCC44.2252C451.F032C451
Description: Binary data