Are there are any DIVX players for the G1?
I am surprised there isnt any search results for DIVX on this, isnt anyone interested in using the G1 to watch movies?
Ok, I noticed a new software (oops a new APP) called Cinema on the market today and I downloaded it. It is supposed to play h.264 and MP4 files, which I have some regular movies (700MB ones) and it does not play those but I have a few low-res ones (160x120) that it does play but jittery. The screen actually looks beautiful and the sound is not jittery but the screen jerks and pauses and you cant get to crop, zoom, aspect ratio, or any of that good stuff to make it fit nicely on the screen. The file extension HAS to be .mp4 for it to show on the list to open. Not too easy for me where my entire collection has a .avi extension.
It is a good start though and a long way from the two original Video players, PLAYS VIDEO and Video Player that played nothing for me at all, not even SHOWED files with .mp4 extension.
Video Player worked perfectly for me but Cinema doesn't detect the same .mp4... We will see much better things in the coming months. I am sure we can even ask DIVX to think about making a player, that would be cool.
4 Months into Andriod and I am losing hopes that we will ever see any support other than the mp4 format. No Divx or any other formats.... I think Google has made it either impossible or very difficult to do anything other than mp4s.
brooklynite said:
4 Months into Andriod and I am losing hopes that we will ever see any support other than the mp4 format. No Divx or any other formats.... I think Google has made it either impossible or very difficult to do anything other than mp4s.
Click to expand...
Click to collapse
Google keeps as much of the Android source under the BSD license as it can. There's some LGPL stuff in there like parts of Webkit and, of course, the linux kernel but that code has to be kept separate from the BSD licensed code. They do this to entice companies to use it because the BSD license allows any one to use the source code without requiring them to release the source of any changes they made to it. However, if a phone manufacturer has to modify the linux kernel, or any other LGPL code, to get it to work on their hardware then they are required to make the source available for those changes. Most companies would not be happy with having to make their source code available so making the Android platform available under BSD makes it much more attractive.
To that end Android needed to have as much of its core components under the BSD license as it possibly could, and that includes the multimedia subsystem. The multimedia system is called OpenCORE and was contributed by PacketVideo. They and other contributing members of the OHA have all agreed to license their code under BSD meaning that any one can take their work and use it in their own projects without having to contribute any thing back. That's no small thing to ask when those OHA members could have licensed that software for a fee instead of giving it away for free.
The reason we can't play some formats like DivX and WMV is because there is no BSD licensed software available that can be included in the Android core. There's plenty of LGPL projects around but an Android developer recently posted on their android-platform group that dealing with licensing issues for Webkit and bluez was extremely painful so I doubt we'll be seeing any of those making it into the core platform.
Another problem is that Google still has not made a native code SDK available. Everything has to be written using the Java SDK and although they attempt to optimize it as much as possible it's still not a fast as native code. Their security model depends on sandboxing applications using the Dalvik VM and native code applications would break that model. Unfortunately, most video decoders would suffer from poor performance if they had to run through the VM. A native SDK is essential for getting these and other CPU intensive tasks (like emulators! I long for a good SNES emulator on this phone) to run well.
So yes Google has made it hard to play video that's not MP4 but it's not because they're trying to be dicks about it.
numerik said:
Google keeps as much of the Android source under the BSD license as it can. There's some LGPL stuff in there like parts of Webkit and, of course, the linux kernel but that code has to be kept separate from the BSD licensed code. They do this to entice companies to use it because the BSD license allows any one to use the source code without requiring them to release the source of any changes they made to it. However, if a phone manufacturer has to modify the linux kernel, or any other LGPL code, to get it to work on their hardware then they are required to make the source available for those changes. Most companies would not be happy with having to make their source code available so making the Android platform available under BSD makes it much more attractive.
To that end Android needed to have as much of its core components under the BSD license as it possibly could, and that includes the multimedia subsystem. The multimedia system is called OpenCORE and was contributed by PacketVideo. They and other contributing members of the OHA have all agreed to license their code under BSD meaning that any one can take their work and use it in their own projects without having to contribute any thing back. That's no small thing to ask when those OHA members could have licensed that software for a fee instead of giving it away for free.
The reason we can't play some formats like DivX and WMV is because there is no BSD licensed software available that can be included in the Android core. There's plenty of LGPL projects around but an Android developer recently posted on their android-platform group that dealing with licensing issues for Webkit and bluez was extremely painful so I doubt we'll be seeing any of those making it into the core platform.
Another problem is that Google still has not made a native code SDK available. Everything has to be written using the Java SDK and although they attempt to optimize it as much as possible it's still not a fast as native code. Their security model depends on sandboxing applications using the Dalvik VM and native code applications would break that model. Unfortunately, most video decoders would suffer from poor performance if they had to run through the VM. A native SDK is essential for getting these and other CPU intensive tasks (like emulators! I long for a good SNES emulator on this phone) to run well.
So yes Google has made it hard to play video that's not MP4 but it's not because they're trying to be dicks about it.
Click to expand...
Click to collapse
WOW this is probably the best answer I have received on this site since I became a member. I guess I was just naive when I thought Google claiming "open source" means easy programming. What I didnt know is that the Google version of open sourse is nothing like Microsoft Windows which is truly open and free to programmers. I wish Google would just charge $50 for the OS and leave it truly OPEN to write programs, or I guess, apps. This whole applet, app, gadget and supposed simplifying thing on the internet is just making it dumber. It seems like Google "open source" means if you want to write a map program with Google maps, its extremely easy and ready made, if you want to use Yahoo maps, mapquest, Microsoft maps etc, its practically impossible. Sooner or later, people would know and stop using andriod.
brooklynite said:
I guess I was just naive when I thought Google claiming "open source" means easy programming. What I didnt know is that the Google version of open sourse is nothing like Microsoft Windows which is truly open and free to programmers. I wish Google would just charge $50 for the OS and leave it truly OPEN to write programs, or I guess, apps.
Click to expand...
Click to collapse
Once upon a time I decided to replace my faithful Treo 650 with a Sprint Mogul. When I looked at the specs of the Mogul from an HTC press release I saw that it had an ATI GPU for 3d acceleration so I thought it was going to be a decent phone. When I got it and started playing with it I noticed that it had really poor performance when playing video. I've played DivX movies using TCPMP without having to re-encode them to lower bit rates or scaled down and that was on a 312Mhz CPU with 32MB of RAM (only 23 of which was actually available). All of those same files were unwatchable on the Mogul. We know now, of course, that the reason was in HTC's poor driver support. Some were able to hack together some drivers for phones like the Kaiser using files ripped from other devices but the Mogul never did get working drivers. The funny thing is that in one of the threads discussing this someone mentioned that the Android source code repository had a linux kernel driver for the same ATI chip and wondered if it could be used to write a working Windows Mobile driver. Windows Mobile truly open and free? Are you sure about that?
brooklynite said:
This whole applet, app, gadget and supposed simplifying thing on the internet is just making it dumber. It seems like Google "open source" means if you want to write a map program with Google maps, its extremely easy and ready made, if you want to use Yahoo maps, mapquest, Microsoft maps etc, its practically impossible. Sooner or later, people would know and stop using andriod.
Click to expand...
Click to collapse
Writing a map program using Google Maps is easy to do because Google built the API into the SDK. You might just as well complain that Microsoft doesn't make writing a map program in Windows Mobile using Google Maps easy. Nothing stops Microsoft, Yahoo, or Mapquest from writing software for the Android OS or providing an API for their services.
I wouldn't give up on it just yet. Adobe announced that Android will have Flash and there's zero chance of them releasing it under BSD as part of Android OS and unless they've discovered some way to massively speed up the Dalvik VM that means that Google is allowing native code to execute within the Android environment; and plugged in to the browser no less. My guess for the reason we haven't seen Flash yet is that Adobe is waiting on Google to make the necessary changes to the underlying architecture that will allow this to happen. The good news is that if its available to Adobe, then native code execution will be available to all and you'll start seeing more interesting apps.
Related
Good evening! I just released the source for my very own slimserver client for windows mobile! (I was very frustrated as I couldn't find any free/open source ones out there).
This is the first release ever, and hence very very basic. Thus, I have only released the source, and no binaries..
It does work, and it does satisfy my current requirements, so I don't plan on spending a lot more time on it. If you want to see it evolving to meet your own needs as well, please do help, by donating your time and coding skills
In order to make it work , you will have to manually edit the libslim\core.cs file with your slimserver details.
There are no GPL notices, nor attributions in the files yet for the various pieces of code that I used. This will change soon!
The scrolling list control is called Kinetic Scroller, and I found it on this forum. Many thanks to dosfan for releasing the source to that excellent and extremely usable control (I did some minor changes).
I found what was the basis for SlimXML somewhere on the web, I don't remember where. Many thanks to the developer In order to compile it, you might need Visual Studio 2008.
You will also need SlimServer version 7 beta installed, as the previous versions do not provide any CLI functionality for browsing the music folders
https://sourceforge.net/projects/pslimclient/
Nice..
This sounds great. Currently I am using the handheld skin and mplayer. It works but a real client would be sweet. The only problem is I don't think I can get a C# compiler. Do you know of a free one or would you be able to get me a binary? I'm running duttys 6.1 on a at&t tilt.
Thanks and good luck with the project.
wr420
hello all and congrats on the new forum
the android in its current state is quite a poor business phone compared to winmo6.1 for a few reasons. can you all chip in in identifying the areas of weakness just to help out developers who want to do something about it
ill start by mentioning the obvious things to me
1. no exchange mail support with search server and html mail(maybe a roadsync port is needed)
2. no mention of vpn support
3. the join domain feature of wm6.1 was kinda useful to some
4. the only platform that can access our eap-tls network in wm5/6.
5. not sure its a big thing, but maybe a basic firewall is needed.
6. an option less integration with gmail (not good for corporations who have security concerns)
7. reader/editor for office 2k7 documents
8. remote desktop (windows, osX, linux)
9. maybe bundling all the buisness features as a single software pack (that does not need to be included with all sold phones if not many people are intrested) this will simplify development and updates.
10. out of box wirless 3g/edge modem or something similar to WiFiRouter.
that's what i can think of for now. feel free to repost this in a more visible android forum
well then don't get it
whats with the hostility. I'm just trying to make android a more attractive platform by highlighting its business shortcomings.
if we can get developers interested in developing these kind of apps early in its life to make it more corporate friendly it would be great.
taking care of business and core features are far more important than cool 'n' pointless apps that the iphone seems to be handling pretty well.
more stuff:
8. remote desktop (windows, osX, linux)
9. maybe bundling all the business features as a single software pack (that does not need to be included with all sold phones if not many people are interested) this will simplify development and updates.
10. out of box wireless 3g/edge modem or something similar to WiFiRouter.
since it's linux I have no doubt that most of your worries will be addressed. I know Linux has a remote desktop app but the question is will the android run non-java apps? Will it have GCC and some libs? Can we download GCC and some libs to our microSDHC cards? Will SSH work? Will the android GUI have X11-like network support? I am not much of a programmer but if the android has gcc and libs I will be doing some compiling of linux apps.
dagentooboy said:
since it's linux I have no doubt that most of your worries will be addressed. I know Linux has a remote desktop app but the question is will the android run non-java apps? Will it have GCC and some libs? Can we download GCC and some libs to our microSDHC cards? Will SSH work? Will the android GUI have X11-like network support? I am not much of a programmer but if the android has gcc and libs I will be doing some compiling of linux apps.
Click to expand...
Click to collapse
Im about 95% certain that all apps run inside android's java environment. Therefore any existing opensource application would have to be ported over to the specifications of android's java language.
Android as an operating system is just a linux executable binary. Think of it like X server. Android is just a GUI, but as of now everything that runs in that GUI has to be specifically written for android.
It may be possible to run seperate tty sessions... and that could allow you to run some sort of server in the background behind android that you could access from inside of android via a web browser (http://127.0.0.1 aka localhost style)
mburris said:
Im about 95% certain that all apps run inside android's java environment. Therefore any existing opensource application would have to be ported over to the specifications of android's java language.
Android as an operating system is just a linux executable binary. Think of it like X server. Android is just a GUI, but as of now everything that runs in that GUI has to be specifically written for android.
It may be possible to run seperate tty sessions... and that could allow you to run some sort of server in the background behind android that you could access from inside of android via a web browser (http://127.0.0.1 aka localhost style)
Click to expand...
Click to collapse
yeah... that's what I thought. I was hoping that wasn't the case.... I can dream right? Maybe it will be like the Zaurus all over again and we can write an X11 environment for it.
Nr. 1, the Exchange feature was mentioned at the launch, and the official answer was "we expect developers to provide applications for that". I think that also applies to the VPN part; since it's that open and that linux-ish, there will probably be lots of VPN/VNC/RDP/SSH clients available.
3 and 4, I don't even know what they are. Stuck in a Windows-based environment, with closed specs ? tough luck. That's vendor lock-in, you know.
5 - a firewall ? what for ? Your device won't be permanently connected, and you probably won't have lots of apps listening on your phone. Anyway, a filtering module will probably appear pretty soon. I'd be more worried about installed apps making hidden outgoing connections (apps calling home, or malicious apps), therefore a good app to have would be something similar to LittleSnitch.
6 - Google has service offerings for businesses, so you either choose to use their services, or you don't. If you don't like it, you shouldn't use this phone I guess
7 - the feature will appear for sure, at least the viewer part. Not hoping of a OpenOffice port for Android, though.
This phone actually doesn't look like it was built for business use, though; just take a look at the apps who won the contest, all of them are focused on fun, socializing, location-awareness and stuff that's useful to people, not business users.
Hmm, to follow up on the Office part:
http://www.informationweek.com/news/personal_tech/smartphones/showArticle.jhtml?articleID=210604042
"We expect it to be more for the consumer, not necessarily for enterprises," says Cole Brodman, chief technology and innovation officer at T-Mobile USA.
The 4.6-by-2.1-by-0.6-inch handset, which will go on sale in the United States on Oct. 22, will let users view Word and Excel documents as well as PDFs.
a few points:
a*you didnt coment on 8-10
b*the exchange feature needs licencing from mirosoft. i doubt the development comunity can do that. unless some genius cracks the airsync protocol
c*if you are on gprs/edge/3g then the phone is Always connected to the network. that why we have things like pushmail.
d*eap-tls is the most secure type of wirless access. and it uses certificates on both the server and client. the client normally needs to be part of the domain to be able to accept the certificate
e*almost all corporations are locked down to windows. its very imortant that buisness phones integrates very well with them if it were to be considered a buisness phones
f*dont you agree that having a buisness friendly is important for the sucess of any phone platform?
g* do you think that the lack of stylus or (resistive lcd) will hinder its ability to do remote desktop? the track ball thingy enough?
Most of the above points (1, 2, 3, 4, 7, 9) will most likely be addressed by developers and sysadmins in good time. In the case of Exchange, even if the platform is opensource, it doesn't mean that a 3rd party company can't license the technology to provide a solution. It might not be pretty (at first), but I wouldn't say it's impossible.
5. It depends on what specific vulnerabilities you're concerned about, whether on the app/run level or somewhere in the core Android stack. In general I doubt there's any issue that doesn't already exist on other mobile OSes, and given their respective solutions, the same is possible here. But if you have a specific concern in mind it would help to point it out.
6, 9. Google is certainly pushing its suite of apps and for good reason (because a lot of consumers use them), but given the open nature of the platform nothing is cemented in place. So while the G1 comes setup for use with gmail/gcal/maps/etc, there's nothing that says a sysadmin can't strip and replace. Moreover, the G1 isn't being pushed as an enterprise device in the first place; there's every possibility that carriers could release other handset models later, preloaded with more business-centric software packages (and less Google apps), and are simply holding off during Android's initial launch. If you think about it, Android has a much better chance of having a strong launch on the consumer front than on the enterprise front. Take care of the former first, then the latter has a better chance of long-term success.
8, g. Same as above, but Google is also pushing the cloud which could lessen the need for VNC/RDP/etc. Sysadmins will have their doubts about security in Google's cloud, but there's nothing that says they can't first observe the model and then later implement their own solution.
10. Not as much of an issue with the software as it is with the carrier. T-mobile isn't just launching Android, it's also launching its 3G network. Providing tethering out-of-the-box could seriously cripple the network in its infancy, and that's the last thing the US 3G market needs. Face it, we need good competition to force carriers to pick up the pace, and in time we could see some competing tethering plans between AT&T, T-mobile, et al.
Some thoughts in general:
Businesses may currently be invested in Windows Mobile for their mobile solutions, but the point isn't to take Android and simply turn it into WinMo -- that would be a wasted opportunity. WinMo users are effectively tied to their PC in one way or another (sync, RDP, svn, tether, etc). Android has the chance to push the cloud (among other innovative models), so that users are no longer dependent on existing workflows. The handset would become just a terminal for accessing the cloud, and transition between terminals would be completely transparent (Android on a phone? How about a netbook?). Not that I expect Android to overtake WinMo (or BES et al), but it gives companies more solutions that better fit their individual needs, and helps MS, RIM, etc start evolving the existing systems that are frankly getting dated.
thanks that was quite insightful
i would like to point out that a big portion (probably the biggest) of the android users only bought the G1 phone because of its great value. think about it the unlocked $399 G1 has more features than the $700 touch diamond. most of these people couldn't care less about what google have in mind for the platform. all they want is for their phone to do certain tasks (like exchange email) a lot of the other google-pushed tasks will probably be unused
I think for you personally, the #1 most important feature the G1 >>needs<< to have is spellcheck
fatso485 said:
...hostiliy...hilighting...buisness...intrested..
Click to expand...
Click to collapse
t mobile is a poor businesses Carrier
most of the big business i have seen use at&t
once tmobile 3g network become more mature they might get some more of the business market. but until they iron out the wrinkles in there new 3g network don't expect anything from tmobile. i don't think you want something like the iphone bill happening to all you business customers.
this is the first step tmobile has taken towards 3g in the US
i am sure there will be some stumbles.
I'm not 100% sure, but I think the Active Sync protocol needed for Exchange support is free to use from Microsoft. I see a LOT of it in many 3rd party email servers and applications. Many of which are in direct competition with Microsoft. So I think we can assume that Active Sync is very doable on the Android platform. Only needs a developer to do something about it.
Active Sync is my main concern too. Once that's in place, then some way to tether I'm getting me an Android phone quickly.
All the other concerns are too easy to fix either already or very soon, so the 2 problems I mentioned are the only show stoppers for me.
There currently isn't even a foolproof activesync drop-in replacement for Linux desktop distros. There's multisync and synCE, but they're both hard to install, hard to configure, and far from perfect in their implementation. As for getting it working under Android, like everything else, it's probably a wait-and-see situation. Most software for Linux isn't written in Java (which Android prefers/requires?) It'll be interesting to see if a java implementation of activesync software could happen.
does any1 know if the g1 has an on screen keyboard
haitiankid4lyf said:
does any1 know if the g1 has an on screen keyboard
Click to expand...
Click to collapse
Currenly, no. The demo and preview vids show that you need to open the hardware keyboard in order to type (except for the phone dialer). But I'm sure SIPs will show up pretty quickly.
fhsieh said:
Currenly, no. The demo and preview vids show that you need to open the hardware keyboard in order to type (except for the phone dialer). But I'm sure SIPs will show up pretty quickly.
Click to expand...
Click to collapse
Yeah, I hope they change that. When I had the Fuze I never liked pulling out the keyboard unless I have to type something long, an email or a long text or whatever. For normal web browsing, entering 1 URL, it's not worth it to slide it open, type and close it again.
my biggest concern is an appointment calender. im so reliant on my appointment calander ion my Kaiser... i wouldnt know what to do without it. Also, a way to sync files would be great. maybe the phone will be integrated with Google Docs? That would be SUPERB! I take notes in my college classes using Office Mobile, but if Android syncs with Google Docs... good lawd.. goodbye to WinMo!
bigdookie said:
my biggest concern is an appointment calender. im so reliant on my appointment calander ion my Kaiser... i wouldnt know what to do without it. Also, a way to sync files would be great. maybe the phone will be integrated with Google Docs? That would be SUPERB! I take notes in my college classes using Office Mobile, but if Android syncs with Google Docs... good lawd.. goodbye to WinMo!
Click to expand...
Click to collapse
Here's a video showing how well it syncs everything.
Say goodbye, WinMo
Hi, I never did that, but I was playing to Anthelion 2 on my PPC and I thank that it could be great to port Homeworld 1 or Cataclysm to the PPC, and I would like to know how to do that, I think that I could "recompiler" it, but I don't know how, and I would like to know if a tutorial has been created somewhere on the net?...
I'm not sure if it would be even technically possible. Well, the newest pdas _might_ be powerful enough to run something like HW1 but i'm not sure if it's such a good idea. Did you try to run homeworld in 640x480 resolution? Most of the time you'll see ships as groups of two to eight pixels. Now imagine it all squished on a phone three-inch screen: try ordering your corvettes to smash that annoying bomber on a screen that small I think that a bit better idea would be porting really old games, that were designed to run in VGA or even lower resolutions (SubCulture, Command&Conquer, I-War, Dark Forces are some of the titles i'd pay for ).
Anyway, back to porting subject.
First of all you would need the source code of the program you want to port - in case of homewrld1 it's not a problem.
Secondly, you would have to make sure that all libraries (graphic, sound, input, etc) used by a game have windows mobile/windowsCE versions. Again, homeworld1 seems lucky since it has been ported to SDL - a multiplatform opensource graphic/sound/input library.
But that's where good news end. Porting a game is not just a matter of grabbing the PC version source and recompiling it. If it was as easy, we would have hundreds of PC games already ported You need considerable programming skills to actually create a port because usualy not all libraries used by a game a compatible with WindowsCE. An example - the opensource version of homeworld uses OpenGL for graphic rendering. The pocket version would have to use OpenGL's "little brother" - OpenGLES. As far as i know, they're not 100% identical, so to put it simply, you would have to make the game talk in OGLES language, instead of standard OGL. And doing changes in graphic rendering routines usually breaks something else, so you'd have to go and fix it.
I'm not trying to discourage you here but i'd suggest learning to program for WindowsCE (or at least for PC) _before_ attempting to port anything - doing it the other way around will be just a waste of time and a source of frustration.
There are some development resources that can help start the adventure with programming here on xda. You could also search for some general C/C++ tutorials targeting PC's. If you consider getting into programming, i suggest checking out SDL - Many games use it, and thanks to this library you can skip the OS-specific part of coding and get right to the fun stuff - a program that actually does/displays anything For an even easier start, you might want to check out QuickCG - a SDL wrapper simplifying the coding even further.
Oki, thanks for your answer, I've a friend who is learning to program in C++, so, I'll ask him if he can help me to do that, it would be great to have this game on a PPC (perhaps the Diamond, because it has D3D and OpenGL Drivers, or of the iPhone, but I guess that the programming language is not the same as the PPC...
[EDIT] STARCRAFT would be great to, and easier to port on PPC, because of his age and that he uses 2d Graphisms...
You should look into the stratagus engine.
antrak said:
You should look into the stratagus engine.
Click to expand...
Click to collapse
Nice Engine, but it's not Starcraft, but I can't find the Source Code on the net, they could give the source code with the game when you buy it
Psycho said:
Hey, it's Calvin, I found him
Click to expand...
Click to collapse
Stargus a starcraft's clone, I'm trying to download it, but I don't know if it works for PPC...
You might want to check this thread:
http://forum.xda-developers.com/showthread.php?t=497086&highlight=starcraft
Before we get caught up in the debate about whether Trident or WebKit is a better layout engine, I want to note that this is irrelevant in this discussion.
The majority of mobile operating systems (eg. iOS, Android, BlackBerry OS, whatever) uses WebKit. This means that there will be some mobile sites that render poorly on Trident regardless of how modern or standard compliant (or not) Trident is.
Of cause up until now, Windows Phone users have been limited to using Trident, but since Microsoft has recently announced that it added native code for development to Windows Phone 8, does this open the ability of porting WebKit browsers and other WebKit components to Windows Phone?
It depends on which libraries WebKit uses for actual graphics output. But given that GDI and DirectX would be where it's at for Windows on the Desktop and that there are differnt UI toolkits on Mac, Linux and Android I guess a lot of the code should be portable to Windows RT and by extension to WP8.
The same should be true for Mozilla's Gecko Engine.
So from my understandig of how things work it should be possible to actually port the existing code instead of having to reimplement it in Managed Code like it would have been necessary for WP7.
We'll have to wait and see until the WP8 SDK is released because currently there is too little known to give definitive answers. Also we don't know if in WP8 you will be able to select a default browser (like in Windows RT) or if it will be IE10 whenever you click a link in an App (like in WP7).
Even though native code can run under winRT, it is not possible to port a browser due to missing APIs. There are numerous articles on this.
Example:http://www.neowin.net/news/mozilla-firefox-would-be-crippled-on-windows-rt
You can't do a Desktop Browser as you are not allowed to run any Desktop-Code in Windows RT. This does not mean that you can't do a Metro only Browser. Although they would have limitations in the JavaScript area as they can't dynamically create code.
WebKit itself should be able to run without too many problems?
illegaloperation said:
This means that there will be some mobile sites that render poorly on Trident regardless of how modern or standard compliant (or not) Trident is.
Click to expand...
Click to collapse
In the long run, this is doubtful. First of all, WP grabs market share, slowly but steadily. Then, there's Opera Mobile which is still being used a lot. Lastly, WebKit features only specific -webkit prefixed features that Trident can't deliver. The more stable HTML5 and all its related standards become, the more unlikely such problems will become. Where actual standards based markup is used (which is what you need to use for either engine as long as you're using something that isn't still prefixed), both engines will render the same pages the same (in the long run, excluding specific bugs).
phailyoor said:
Even though native code can run under winRT, it is not possible to port a browser due to missing APIs. There are numerous articles on this.
Example:http://www.neowin.net/news/mozilla-firefox-would-be-crippled-on-windows-rt
Click to expand...
Click to collapse
a) WinRT isn't exactly what WP8 will use.
b) Windows 8 features a specific Metro web browser application model which permits this after all. (Although I doubt we'll see this being available in WP8)
illegaloperation said:
Of cause up until now, Windows Phone users have been limited to using Trident, but since Microsoft has recently announced that it added native code for development to Windows Phone 8, does this open the ability of porting WebKit browsers and other WebKit components to Windows Phone?
Click to expand...
Click to collapse
The question is rather, will Microsoft permit alternative browsers? If you look at the situation now, a few Trident based ones are available - but something like Firefox or Chrome is a different thing. After all, Apple doesn't permit Firefox to use Gecko either.
Looking at phailyoor's Link it becomes obvious that you don't have certain possibilities in the WinRT Framework. You can't launch child processes (threads yes, but not processes), which is often used to decouple separate Tabs so a crash of one Tab doesn't crash the whole browser.
The second problem is that in WinRT you can't mark memory as Executable. Therefore you can't do dynamic compilation of JavaScript to machine code which would further on prevent a fast implementation of JavaScript. This would make many modern HTML5 pages likely to be really slow.
Microsoft won't ban alternative browsers but currently it seems like browsers based upon WinRT (e.g. as a Metro App) don't make a lot of sense.
So now that the SDK has leaked, can anyone provide update information on this?
Don't think we'll see one (or at least a good one) any time soon. Here's all the C++ project templates. So basically they would have to use Direct3d which I can't see happening without a lot of effort. Also, like mentioned above, I believe Windows 8/RT has a specific cutout to allow for browsers. WP8 definitely does not.
Windows Phone Direct3D App
A project for creating a Windows Phone app that uses Direct3D.
Windows Phone Runtime Component
A project for creating a Windows Phone Runtime component for a Windows Phone app.
Empty Dynamic Link Library
A project for creating a native dynamic-link library for a Windows Phone app.
Empty Static Library
A project for creating a native static library for a Windows Phone app.
They could always build it as a run time component and wrap it in .net/xaml. I think Chrome or Firefox for Windows 8 does the same.
HI, I saw some apps on play store and WP market. I found that many apps on WP are smaller in size as compared to the same app on Android.
Examples:
Official Twitter app: By Twitter
Android : 6 MB
WP : 2 MB
Facebook app:
Android (official) : 13 MB
WP ( by Microsoft) : 4 MB
LinkedIn app (Official)
Android : 5MB
WP : < 1 MB
NY Times (Official)
Android : 2.3 MB
WP : 1 MB
Whatsapp : By Whatsapp
Android : 8 MB
WP : < 1 MB
Foursquare (Official)
Android: 10MB
WP: 5 MB
Angry Birds Star Wars
Android: 38 MB
WP : 20 MB
Angry Birds Space
Android : 36 MB
WP : 15 MB
Anyone viewing this thread, please post apps sizes if you also find same thing for any other app.
So, how do will explain this small app sizes on WP compared to Android.
Is WP OS more CODE efficient than Android
Does this efficiency contribute to smoothness of apps. Please share your thoughts.
As a developer, I can say for certain several things
1) Yes, the OS is way, way more "code efficient" than Android
2) The code is downloaded and compiled only once. I will not get into details as to why this is happening, but on Android, as far as I am aware, JIT occurs everytime you run the application.
Also, Visual Studio is able to create far smaller binaries when compared to Eclipse.
Bytecode(android+eclipse) tends to produce really large "binaries" while the IL(WP+VS) tends to create very effective "binaries".
My game, which contains around 100 graphical assets only eats around 5.53 MB of space. So yes, C#/C++/VB handle assets and binary size better than Java.
There's been some talk lately about porting Android to use C# instead of Java. Some tests were done as far as performance is concerned. Really interesting results
http://www.cnx-software.com/2012/05...-massive-performance-improvement-over-dalvik/
http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
Then there is also the problem of hardware variety. Windows Phone basically runs on the same chipsets and only has a few supported resolutions, whereas on Android, there are great many chipsets, each with their own sets of hardware assets and many possible resolutions. Developers need to write more code to make sure their apps work fine on as many phones as possible.
mcosmin222 said:
As a developer, I can say for certain several things
1) Yes, the OS is way, way more "code efficient" than Android
2) The code is downloaded and compiled only once. I will not get into details as to why this is happening, but on Android, as far as I am aware, JIT occurs everytime you run the application.
Also, Visual Studio is able to create far smaller binaries when compared to Eclipse.
Bytecode(android+eclipse) tends to produce really large "binaries" while the IL(WP+VS) tends to create very effective "binaries".
My game, which contains around 100 graphical assets only eats around 5.53 MB of space. So yes, C#/C++/VB handle assets and binary size better than Java.
There's been some talk lately about porting Android to use C# instead of Java. Some tests were done as far as performance is concerned. Really interesting results
http://www.cnx-software.com/2012/05...-massive-performance-improvement-over-dalvik/
http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
Then there is also the problem of hardware variety. Windows Phone basically runs on the same chipsets and only has a few supported resolutions, whereas on Android, there are great many chipsets, each with their own sets of hardware assets and many possible resolutions. Developers need to write more code to make sure their apps work fine on as many phones as possible.
Click to expand...
Click to collapse
Oh boy. Where to start.
Firstly, the WP OS is not more efficient than Android. Android consists of Java in the form of the Davlik virtual machine running on linux. In no way is this less efficient than C# running on the WP8 virtual machine on the NT kernel.
Bytecode is not Android + eclipse. Eclipse is an IDE, like visual studio. Bytecode is the compiled output from the Java compiler in the form of .class files. You can use any IDE (or none) to develop Android applications.
The size of a binary bears very little relation to it's efficiency. It all depends on the environment it runs under. For example, a single API call may, in one environment, relate to, say, 20 calls into some framework that is bundled with the app - therefore making the binary bigger. In another environment the single call may result in a single call into a function provided by the virtual machine. The end result is that roughly the same amount of code is executed. Also, part of the reason why Android binaries are larger is because they contained a cached version of the app for quicker startup.
Besides code, a binary may contain other artefacts, like graphic files or different resolutions, which will make the binary bigger.
The idea of using C# on android is absurd. C# is not supported on Linux (by Microsoft). There is, however, the mono open source version of C# (always guaranteed to be out of date) but the android libraries provided by Google are written in Java and there is no way they will use a proprietary language, like C#, as it will require the use of Microsoft technologies to run and that means they will have to pay Microsoft a license fee.
Why on earth would the leader in smartphone abandon their existing technologies to adopt one that will require a complete redevelopment of Android and, in addition, pay a license fee to Microsoft? Answer == they won't. Ever.
Dr.Paul said:
Oh boy. Where to start.
Firstly, the WP OS is not more efficient than Android. Android consists of Java in the form of the Davlik virtual machine running on linux. In no way is this less efficient than C# running on the WP8 virtual machine on the NT kernel.
Bytecode is not Android + eclipse. Eclipse is an IDE, like visual studio. Bytecode is the compiled output from the Java compiler in the form of .class files. You can use any IDE (or none) to develop Android applications.
The size of a binary bears very little relation to it's efficiency. It all depends on the environment it runs under. For example, a single API call may, in one environment, relate to, say, 20 calls into some framework that is bundled with the app - therefore making the binary bigger. In another environment the single call may result in a single call into a function provided by the virtual machine. The end result is that roughly the same amount of code is executed. Also, part of the reason why Android binaries are larger is because they contained a cached version of the app for quicker startup.
Besides code, a binary may contain other artefacts, like graphic files or different resolutions, which will make the binary bigger.
The idea of using C# on android is absurd. C# is not supported on Linux (by Microsoft). There is, however, the mono open source version of C# (always guaranteed to be out of date) but the android libraries provided by Google are written in Java and there is no way they will use a proprietary language, like C#, as it will require the use of Microsoft technologies to run and that means they will have to pay Microsoft a license fee.
Why on earth would the leader in smartphone abandon their existing technologies to adopt one that will require a complete redevelopment of Android and, in addition, pay a license fee to Microsoft? Answer == they won't. Ever.
Click to expand...
Click to collapse
Uhh...
Where do I start?
I know bytecode is NOT android+eclipse, I only mentioned the IDE and System, just as IL si not visual studio.
The size of the binary is influenced by how good the compiler is. Although it is not the only the only thing to take into consideration, the compiler does have a role in this.
C# on Linux/Android/Mac/iOS IS supported by Microsoft under the community promise license, so everybody can port C# and .NET to any system as long as they don't use this on windows, WITHOUT having to pay Microsoft anything... I suggest you get some documentation on what Mono and Dalvik are.
C# is just as open source as C on any platform apart from Windows.
As a matter of fact, porting Android to C# would benefit the platform greatly, as google has some issues with Oracle regarding the usage of Dalvik and Java on Android.
Oh, did I mention android has to code MORE due to variety of code...hmm...
No. You cannot judge the efficency of the compiler based on the resultant code size unless you are comparing like for like. You cannot compare two languages running on two different platforms like this and come to the conclusion that because the bytecode is smaller it must be more efficient.
I expect you are too young to remember the CISC vs. RISC debate some 20 or so years ago. RISC processors generated far more instructions than a CISC processors to perform the same operation, and hence had far larger binaries. However, RISC machines were far faster. So the complete opposite of what you are saying.
Different compilers may well generate different size binary files if one were to compare compilers compiling the same language. But again this does not mean the code in the smaller file will run quicker. Indeed it may actually run slower.
Code size is no indicator of efficiency.
As far as c sharp is concerned, only the language is free to use. None of the frameworks are. And Microsoft do not provide a c sharp compiler on any system besides windows.
There is not a chance in hell that Google will adopt it. If they were to change from java they will either use one of the languages they have developed or develop something new
I used the appropriate quotation marks when writing "code efficient", as it is a very broad term and comparisons over who is code efficient and who is not.
The way I understand it, a code efficient system is a system that has very high performance, such as windows phone, not that it has anything to do with size of binaries, but the OP asked if WP is a "code efficient" system, so i answered xD
.Net framework is also free to reverse engineer. You still have to pay for compilers however.
Interesting sidebit: in internal Google E-Mails that got published during the Oracle vs. Google trial over Java it was actually mentioned that using C# instead of Java would have been an option due to the fact that there are less licensing hassles attached to it's core library (which actually is standardized with ECMA) as compared to Java. They decided not to go that route as it would have taken a year to adapt Android and instead risk getting sued by Sun (which was later acquired by Oracle). So: yes, C# would have been just as good an option. Using something like Google Go wouldn't have simply because there was no developer community and it's a lot easier to get people working on your platform if they don't have to learn a new language first.
That aside: most likely the binary size isn't all that much relevant for how big the downloaded files are. And I won't even go into the fact that some of those Apps aren't written in Java on Android but use the NDK (at least Facebook and the Angry Birds games do on Android, most likeley the later do it on WP8 too).
So in the end it's most likely down to the embedded Audio and Graphics resources. As was already mentioned Android devices have to support a lot more resolutions which makes it likely that LowRes graphics are included as well to not tax slower devices with high-res graphics for no reason (given that you won't see the difference on LowRes displays). Another reason for this with regular Apps is that WP takes a chromeless-design-approach so you rarely have graphics included that serve as UI chrome.
Another reason might be that Microsoft put quite some effort into driving home the point that resources should not be included or used in a higher resolution than what they are intended to be displayed at. The reason was that it might have led to troubles with the memory-constrained Tango-devices which only have 256 MB of RAM. At least for high-profile developers that work together with Microsoft it's likely that those optimized their Apps for it.
Lastly and also already mentioned: third party libraries. Historically Microsoft has always packed a lot of functionality directly into it's system frameworks. So it's entirely possible that WP devs use third party libraries less often. Case in point: database functionality: many Android Apps use SQLite and include their own binaries for it. WP provides SQLServer CE which can simply be used by any App that needs it. This might change though as for W8/WP8-cross platform Apps Microsoft themselves suggest including SQLite given that there is no SQL CE Support for WinRT-Apps.
And for the finishing lines something on compilers and code size. Intels C++ compilers regularly produce bigger binaries because of optimization techniques like loop unrolling, etc. They also normally outperform competing compilers in performance benchmarks. But it's not that easy if you look not at a single App's performance but at the whole system. Having an App take up more memory means that other Apps will have to be terminated sooner to avoid an out-of-memory scenario and it is more taxing on the memory controller, which depending on the chipset used might lead to additional performance problems down the road (the Nvidia Tegra 3 is said to be severely limited by its memory controller). But especially with Managed Code like C# or Java the code size of the IL does not really mean too much in that regard as the code is compiled anyway before being executed. So the memory actually taken up during execution is a lot different from what gets downloaded.
A more interesting comparison though would be wether the WP8 compiled XAPs are smaller than their WP7 counterparts, given that WP8 does precompile the IL in the cloud. Might be interesting to see which of those is smaller.
Just did some comparisons on size of binaries between 7.5 and 8
1) XAP compiled for 7.5 is 5.53 MB
2) XAP compiled for 8 is 5.76 MB
Seems the 8 version is actually bigger, although not by much.
I love this thread!
Sent from my RaZr on MIUI.
I know about the comparison between Android and Windows Phone 8 from users who have made the switch.