ubuntu-phone team mailing list archive

[Josh Leverette <coder543@xxxxxxxxx>]

Navigation being different from Android and iOS will not be an issue -- a
quick first boot tutorial screen can explain it easily enough. The lack of
apps is far more threatening, but supporting Android apps simply *is not an
option*. Even if it were a good idea, it still isn't an option. You don't
realize how large of an undertaking it would be, and how poor the result
would be. All of the engineering talent wasted on making a poor Android
emulator for Ubuntu would then cause the rest of the operating system to be
of even poorer quality since no one would have time to work on that if
they're going to finish the emulator in time. That's a gambit you're not
going to recover from. If you think it is so easy, that's why you're free
to develop it, but you'll quickly find out on your own that it isn't a good
idea.


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

> If ways of navigation are completely different, then I would doubt how
> touch would be successful in the market. People are familiar with android
> and ios, how would people go choose one thing that's completely different,
> and with just a few apps. Unless touch is as innovative as ios in 2007, and
> the marketing people are as good as Jobs.
> I hope the marketing people have thought about this.
>
> ------------------ Original ------------------
> *From: * "Alfred Neumayer"<dev.beidl@xxxxxxxxx>;
> *Date: * Fri, Jun 21, 2013 09:22 PM
> *To: * "ubuntu-phone"<ubuntu-phone@xxxxxxxxxxxxxxxxxxx>; **
> *Subject: * Re: [Ubuntu-phone] Qt5 and touch performance issue
>
> You are making it sound easier than it actually is.
>
> The effort that would be required to have a decently working
> Android-compatibility layer is
> not worth the hassle IMO, since it would put us in the same category as
> Windows 8, where you have 2 completely different types of apps (Desktop &
> "Metro" apps : Ubuntu SDK & Android apps).
>
> I would not want to have 2 completely different types of apps with
> completely different ways of navigation and fundamental technical
> differences on my smart phone.
> What value does app compatibility bring if the user experience is crap?
>
> Am 2013-06-21 15:16, schrieb leon lee:
>
> 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><thomas.voss@xxxxxxxxxxxxx>
> ;
> *Date: * Fri, Jun 21, 2013 09:00 PM
> *To: * "leon lee"<llrraa@xxxxxx> <llrraa@xxxxxx>; **
> *Cc: * "ubuntu-phone"<ubuntu-phone@xxxxxxxxxxxxxxxxxxx><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: 627B807C@5ECCD815.1F5BC451.bin
Description: Binary data