Slashdot Mirror
Microsoft's Plan To Port Android Apps To Windows Proves Too Complex (networkworld.com)
An anonymous reader writes: The Astoria project at Microsoft has failed because a breakthrough was needed to overcome the complexity of the software development challenge. Microsoft tried to automate mapping the Android UI into the Windows 10 UI and to map Google services within the app such as maps, payments and notifications into Microsoft equivalents. Automated conversion of a UI from one platform to another has never been successfully demonstrated. When I first saw Microsoft's Android bridge at Build 15, I thought it was achievable. But project Astoria, as it is called, is much too complex. Drawing on my architectural knowledge of the underlying Microsoft/Lumia hardware that is very similar to Android phones.I concluded that in the context of partitioning the device or running a VM Microsoft would succeed. But Microsoft tried something much more ambitious.
Rather than "failed," The Next Web reports that for now the project may have only been delayed.
But kudos for pointing it out.
Honestly now ... did anybody believe this could be achieved? I'm pretty sure lots of people looked at this and thought "yeah, right, never gonna happen".
This is why people have been maintaining cross-platform libraries to solve this problem -- because it's a huge and difficult problem.
Automagically converting apps from Android to use all the Windows stuff? That always sounded like a pipe dream. They'd be better off writing something like a reverse Mime to allow native Android apps to run on Windows.
I am not in the least shocked Microsoft isn't going to create the magic path to putting Android apps on Windows phones. And, honestly, I'm not sure the Android users ever expected to care about this, this was all about trying to lure people to Microsoft's platform.
As usual, Microsoft can only see the world through their own lens, and have yet to demonstrate they know what people are actually looking for.
Lost at C:>. Found at C.
I thought all Android apps were just written in Java, you know, that language that is supposed to compile and run on any platform?
Running android on my phone, I notice that there are a lot of very buggy apps. Even assuming the apps all worked perfectly, I imagine it'd be way hard, but with buggy ones...
All they have to do is license GenyMotion.
It's meant for Android developers, but could work for this with a new skin. It runs X86 Android in VirtualBox So, you build your project for X86. I build for dual X86/ARM and use the same executable on physical devices and GenyMotion.
I run it on OSX. It really is the only practical solution for Android simulation on desktop. The Google-supplied emulator is dog-slow to the point of total uselessness, and Intel Haxm isn't much better. GenyMotion is a joy.
Don't work for them, just a happy user!
It is pricy, but they have a $99/year option for Indie developers. (I think individual or company with 3 or fewer developers.)
I'm sure Microsoft could cut a deal.
All they have to do is license GenyMotion.
It's meant for Android developers, but could work for this with a new skin. It runs X86 Android in VirtualBox So, you build your project for X86. I build for dual X86/ARM and use the same executable on physical devices and GenyMotion.
I run it on OSX. It really is the only practical solution for Android simulation on desktop. The Google-supplied emulator is dog-slow to the point of total uselessness, and Intel Haxm isn't much better. GenyMotion is a joy.
Don't work for them, just a happy user!
It is pricy, but they have a $99/year option for Indie developers. (I think individual or company with 3 or fewer developers.)
I'm sure Microsoft could cut a deal.
(Sorry for dupe, posted first as a response to existing with irrelevant subject. Slashdot, do we still have to party like it's 1999? How about ability to edit posts?)
Microsoft has an amazing history of backwards compatibility. I mean, the SimCity hack is just my favorite, but they go on and on. If anyone can overcome the delays (not failure) in porting over Android programs, it's Microsoft.
And that's without taking into account their EEE mehtodology. Excel took off the same way, being 100% compatible with 1-2-3.
I don't understand why the GUI would even be difficult. There are a finite number of calls. All they have to do is be slavishly followed. If you want to make the GUI feel more MS'y, that'd be difficult. But first they embrace, then add a few MS only options, then boom.
Your ad here. Ask me how!
Yes with ARC welder from Google, I can run Android apps on my Linux machine and possibly others.
"The hallmark of humanity is the ability to move beyond sensory inputs" - Mary Helen Immordino-Yang
The Android API is some thousands of functions. Android and Google already implemented that API on top of Linux . I don't see any fundamental reason that a company with Microsoft's resources -couldn't- implement the same API as follows:
Android.textbox.Draw(blah, x, y) {
Winforms.textbox.Draw(x, y, blah);
}
Sure there are thousands of functions, but Microsoft can put hundreds or thousands of programmers to it. It's not an easy task, but mostly it seems -big-, lots of functions, not necessarily anything all -that- complicated.
Looking at it another way, not only did Android and Google implement the Android API, Google also re-implemented the Java API from scratch, while the Mono project and Wine have re-implemented the Microsoft APIs. Given that they've done that, I don't see how it would be impossible for Microsoft re-implement the Android API, mostly with simple stub functions which call the corresponding Windows function.
Actually, the original poster is wrong, automated conversation from one platform to another has been done at least one time in the past, check out Project Odin which could on the fly automatically convert a Win32 binary into a native OS/2 binary.
Google would enjoy suing MS for a gazillion dollars! It could not happen to a nicer company.
The good stuff uses native code. There is an NDK = "native development kit"
I write hybrid apps, using the Rhodes cross-device platform. So, UI is a webview. The platform uses some Java on Android, but mostly C and C++, because it can use the same code used on iOS and Windows CE/Mobile.
So, Rhodes uses Java on Android where it uses Objective-C on iOS - to interface to native APIs.
Phonegap would be great for apps written with PhoneGap! If they can get the authors to publish for Windows.
PhoneGap apps use a combination of Javascript and native plugins.
PhoneGap won't "convert" some arbitrary app that is written with Java and/or the NDK.
Or something like VMWare? Or did they really want the apps to look like native apps? That I'd get. I wish I could run many of my iPad apps on my MacBook...there already is a simulator, so it must be close.
This reminds me of when IBM had the mistaken notion that if they added Windows 3.x compatibility to OS/2 they'd be the platform of choice.
You'd think Microsoft of all companies would remember that logical fallacy of that plan.
You were mistaken. Which is odd, since memory shouldn't be a problem for you
Very simply, Microsoft has to work on the Universal apps - making as many apps available on Windows 10 Mobile as there are in the mainstream Windows 10 platform.
Also, Microsoft should identify and work on helping vendors port some major apps in the market - like Uber, Lyft, Vonage, et al to their platform. Do a drive so that most apps that are already there for both iOS and Android are also ported to Windows 10 Mobile. It doesn't have to be most, or even a majority of apps, just the ones that are already indispensable.
Not really. From what I understand, the plan was to make it easy for developers to port over apps they wrote for Android without having to re-write it for Windows (an automated conversion), not to provide a compatibility layer. Basically to re-compile the code in such a way that it becomes a native Windows app.
...is the one loosing.
Clarifications and further details:
Re: "to support and wade through even if you never change UI methods"
Change: "to support and wade through even if you never change UI frameworks or platforms"
Re: "For big projects, multiple viewing, searching, and grouping angles becomes more useful."
Change: "For big projects, multiple viewing, searching, and grouping angles becomes more valuable to help deal with the volume of (UI) code."
Re: "UI-related code doesn't necessarily have to "run" in the table, for compiled languages could have the IDE generate file-based code..."
Note that interpreted languages could optionally do an "eval()" function on code in tables. Or they can use the same technique mentioned for compiled languages, but it's an extra code preparation step. Or just store attributes in tables, not methods. But one may be able convert common method behavior into "action" attributes, such as opening a given screen in an "on-click" event.
A lot of GUI activity has reoccurring patterns that can be parameter-ized rather than rely on lots of explicit app code. That way more of the GUI activity is attributes instead of direct code, reducing the tricky issue of how to execute UI-related app code. I'd say at least 3/4 of GUI activity can be readily parameterized in such a way. It's just not the habit of GUI engine/API designers to think that way because they are writing for coders, not attribute "programmers".
(And added advantage of such a system is that it's less language-dependent. You do most GUI "coding" by setting attributes and action-lists having parameters, not using a specific app language.)
Regarding dynamic relational, generally each widget will have a fixed or common set of attributes, such as an ID, container ID/ref, title, default value, sequence or coordinates, widget type, etc., but also have a widget-type-specific set of attributes. Traditional RDMBS don't deal with these widget-specific attributes very well, and this may be why the idea hasn't really been tried. (Visual FoxPro did it to some extent, but mostly didn't expose it to the coder. OODBMS may use sub-classing for widget-specific stuff, but that creates other problems, especially if the differences are not clean "type" hierarchies.)
Table-ized A.I.
Microsoft did include decent Cordova (Phonegap) integration into Visual Studio 2015 including native Windows and Android build process with connected device deployment, and remote build on networked Mac for iOS builds and deployment.
Maybe Microsoft should flip things and make an Android phone (with 100% Android compatibility) but possibly with Windows style tiled home screen (optional for users) but also have a Windows 10 Mobile native programming interface (to give Windows 10 developers easy access).
The development model of Windows 10 Universal Windows Platform is pretty cool (phone to tablet to laptop to desktop to tv). The ui tools are there to make this not too difficult to take advantage of.
BB10 QNX phones run Android apps just about as well as they run natively from what I can tell.
Why not port the Java Virtual Machine, then using the MS widget set/chrome? E.g. RoboVM uses this to run Android Apps on IOS.
It also has great market share and just works.
For small values of "works".
There is no such thing as too complex especially when you have the resources of Microsoft. All you have to do is to emulate the Android API at a high level. The only problems are those application that have native Linux binary code.
Can you post a link to your research?
You were mistaken. Which is odd, since memory shouldn't be a problem for you
Their existing developers were none too happy about all the time they spent on native apps being made worthless under a deluge of quick and dirty ports.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Automated conversion of a UI from one platform to another has never been successfully demonstrated.
Isn't this the definition of an emulator?
Not to contradict your point in any way, but Uber has been available on Windows Phone for months, possibly years. Lyft is not, though. It's a WP8 app, but will run fine on W10M.
There's no place I could be, since I've found Serenity...