I'm developing an app which only for windows 10 desktop currently
(I didn't do too much with touch event, focus on mouse event now, and mobile platform should comes with other layout)
I'm wondering, can I submit an app to windows store and set the app only for desktop ?
it's built with universal project which support for all platforms, but best experience is for desktop platform for now.
In the appxmanifest file, the target device family can be set. It is Windows.Universal by default, but if we set it to a particular device family, the app will run only in that device family.
<Dependencies>
<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.0.0" MaxVersionTested="10.0.0.0" />
</Dependencies>
This answer might help you - https://stackoverflow.com/a/31727029/4575252
Related
My app, basically, needs to do the following:
getting GPS coordinates
calling web services (for accessing, sending info etc)
work in background with no UI for most of the time
The target device is a mobile tablet running with Windows 8.1.
I found out that for this OS I can develop both a desktop app or a Windows Store App.
Please, what do you suggest to use for my needs?
Also, because I dont know Windows Desktop App at all, Please can I get everything done using a desktop app?
Thanks
the main difference between those two is, whether or not you get a window in your old-school desktop (desktop app) or one of those fancy full-screen-app thingies that were introduced in Windows 8... Afaik you can't sell the Desktop apps on the Windows Store, but functionality-wise your average desktop app has no real downside as you can use .NET with all fancy features for both...
Here you can find a detailed comparison between both. But from your description you should be fine with the desktop app (:
Cheers D
I would go with the desktop app simply for the background tasks you mentioned. This is tricky to do in Windows Store apps as Windows tombstones (freezes) the apps if you navigate away for any length of time. As far as I know, only certain apps, such as music apps, can run in the background.
Desktop apps have no such limitation.
I am trying to find Simulators for multiple mobile Operating Systems, but i am always getting Emulators instead.
What i need basically is maybe a Web Version of different mobile OS, not to run or test applications, just to navigate through their menu and settings (go at settings, change settings, setup email etc.)
The purpose for this is to guide through users on how to change their settings on their phones, without the need of the actual device or having multiple emulators.
UPDATE
After a lot of search around i managed to find an Android web simulator that suits my needs at Manymo.
It has versions : 4.2 , 4.1 , 4.0.3 , 2.3 , 2.2 , 2.1
Still in search for something similar for iOS, Windows Phone and Blackberry.
You could easily set up such emulators with a bit of CSS and jQuery (for the animations when changing screens).
From time to time I run into such "simulators" on cell-provider companies' websites. But they are very limited to a teaching a few functions, and are accompanied by text on the side.
You might want to hire a web developer, give him 3-4 days and then you have a nice simulator for the 3 popular OSes.
Just beware that having an Android simulator may not be enough; The OS changes with the devices, as manufacturers do whatever they want with the OS and compile for their specific device.
Have you considered creating a free account on http://deviceanywhere.com?
There are some 'fun' apps built for Windows Phone to emulate other phones
iFun - iPhone simulator
Fundroid - Android simulator
B7B - BlackBerry simulator
I haven't tried them out myself so I can't say how well they simulate phone settings, but is this kind of what you're looking for?
Something like http://www.mobilephoneemulator.com/ then perhaps. Or do you want it for apps rather than web pages? Then I don't think it's possible.
There are packages like jQuery Mobile that is designed to generate web apps that look like native mobile apps.
I am about to start the development of an Windows 8 app. The app is supposes to run in phone, tablet and desktop. I went through lot of docs in msdn sites and this is what I understood from them.
There is no way to create one project which supports both phone and (tablet,desktop).
User can create a Portable class library project and put all the reusable code into it and add it as reference to the actual projects.
create one project for windows phone and one project for window store app(create using dev account)
Please correct me if I am wrong and also let me know if there is any other way of doing it. Also I understand like the window store app will work for both tablet and desktop whereas windows phone app works only in phones and not in tablet.Is it right?
Windows tablet comes in two flavours, Windows Pro and Windows RT.
Will the desktop store app work on both the tablets ?
is there different development environment for different category of tablets?
This month I started to play with Flash Builder because I don't have a mac to create native iPhone apps.
I have made a Flex Mobile Project and an AS3 Mobile project. Both do mostly exact the same and I see great differences in operation speed (AS3 version is much faster). Also the size of the AS3 version is less than the size of the Flex version when I deploy the project.
But one thing disappoints me, the size of a deployed AS3 app (Android) is still about 8MB. I think that is quite huge for a simple app, or is it normal? I did not test the iOS version because I am not an Apple Developer member (is there a trick to deploy an iOS app with fake certificates)?
Resources I have used in the apps:
Two images approx. 35kb in size
A StageWebView
I want to know:
What is the average size of a simple app when it is a native app (apk file)?
What is the difference between an AS3 app and a Flex app except the libraries that re used?
Is the AS3 app converted to C or another language?
Why is the apk so huge (IMO)?
Is there a trick to deploy an iOS app with fake certificates? (just for testing)
Thanks for the answer(s).
What is the average size of a simple app when it is native app (apk file)?
I have no idea. When you were comparing sizes; did you export a release build or a debug version? The full version of my app; using Captive Runtime is 12MB. That includes all the embedded images. I thought that roughly 8MB is the size of the embedded runtime. Of course, if you don't use Captive Runtime then the app will be smaller; but it will have a depency on the user having the runtime installed.
What is the difference between an AS3 app and a Flex app except the libraries that are used?
For all intents and purposes nothing. The Flex Framework will need to execute code to setup the framework and such. In theory this 'impact' is offset by the value that the framework brings.
- Is the AS3 app converted to C or other language?
Not for Android or Playbook. It relies on the Mobile AIR Runtime--which I assume is written as a native app somehow. For iOS there is a more in depth conversion taking place; but no on knows the exact magic sauce; but it the process is much more intensive than Android or Playbook and people believe that your code and the AIR Runtime is converted to Objective C somehow in a way that is not in violation of the Apple licensing agreement.
Why is the apk so huge (IMO)?
Huge is open to interpretation. Without seeing your full app code; it's tough to judge.
Is there a trick to deploy an iOS app with fake certificates? (just for testing)
I don't think so; although there may be possibilities on unlocked devices.
You would like to use Mobile AS3 Project if you want you apps to be smaller and your GUI mainly contains vector graphics and Mobile Flex Project if you prefer to use standart GUI Controls that comes together with Flex framework but adds overhead in size because of controls that come with it.
As of the other questions:
the size of the apps is different on mobile platforms. Typical iOS app is about 2MB - 20MB. It really depends on resources you store with your app. What might be important to you is not to overcome 20MB if not needed because 20MB+ apps require Wi-Fi connection to be downloaded.
(However you should export release build version only as mentioned by www.Flextras.com)
there is no fundamental difference between AS3 and Flex apps - they both compile to the same instructions that executes on targeted mobile platform.
as far as I know (being iOS developer myself) there is no workaround to deploy an iOS apps. You need to use Mac and become Apple Developer to deploy with valid certificate.
to make your app smaller try to pai special attention to the resources you add to the project. Although I believe the size is so big because of framework itself, you would like to use more vector graphics vs. bitmaps when compiling apps with Flash/Flex.
When you export for Android you have an option of embedding the air framework in the application, that way your users don't have to download air. you can export your application without air embed which will result in a much lighter application, however your users will need to download air runtime. http://cookbooks.adobe.com/post_How_do_I_create_an_AIR_application_for_Android_tha-19299.html
I am building an enterprise application using HTML5 for Blackberry OS 6.0. I am planning on using PhoneGap for developing the application. I found out that Blackberry also has something similar called WebWorks.
What are the differences between WebWorks and PhoneGap?
PhoneGap-BlackBerry-Widget uses the BlackBerry Widget SDK to support BlackBerry OS 5.0 & 6.0. WebWorks is basically Widget SDK 2.0 and it is intended to support OS 6.0 specific features.
The advantage of using PhoneGap-BlackBerry-Widget over WebWorks is that you can port your application to other platforms that are supported by PhoneGap.
You can still port an application that was written using WebWorks/Widget SDK, but you will need to switch out the BlackBerry-specific JavaScript bindings for the PhoneGap JavaScript bindings (e.g. invoking Geolocation, contacts, or accelerometer).
Looks like WebWorks is specifically for BlackBerry while PhoneGap is attempting to support multiple mobile platforms.
I haven't looked too deeply into WebWorks, it appears to be more tightly integrated with a specific device, a Blackberry
WebWorks is a specific development tool managed by RIM for BlackBerry, while PhoneGap is in the MEAP (mobile enterprise application platform) space where they represent the next generation of mobile development. You develop your app with PhoneGap and it helps you to deploy across all major platforms such as iPhone, Android, Windows Mobile and BlackBerry. If you're a developer then it opens the doors to more phone models and increased opportunity for app sales.
webwork vs phonegap
both are used for build application .using webwork u get for feature for specially blackberry....using phonegap u can use same code for multipal phone like iphone,android..
but i prefer webwork because phonegap add unwanted code to your applicatio due to application very slow ....phonegap + wework in blackberry 5.0 take too much load...it's min size is around 600 kb......
so for blackberry webwork is better than phonegap
One issue to consider is testing and compiling applications.
When testing on devices and simulators it is possible to compile/sign once and access/edit your JavaScript and HTML5 from a remote location, such as the SD Card or a local server. While PhoneGap and WebWorks are both using JavaScript to access native functions, I have found the 'compile once' method doesn't seem to pick up and utilise PhoneGap - this is also the case with the Ripple emulator. In my experience, using PhoneGap requires multiple, time-consuming compilations and launches when testing an application. If testing on a Blackberry device, you need to factor in the time it takes to have your app signed prior to each test and the time it takes for the device to reboot. I'm talking 2+ mins on a simulator or 4+ mins on a device, per each change to your code.
I'm working with webworks for Blackberry and phonegap for iPhone. Not sure whether the problem is with webworks or underpowered handsets but we've had to spend a lot of time ripping features out of the webworks app to get any kind of robustness or performance when running on the device. Static google maps and thumbnail photos had to go.
All webworks apps on a handset share the same pool of memory, about half of the memory available to the BB browser. Webworks also leaks memory. There's a thread a year old on the webworks forum about the memory leaks and no solution forthcoming from Blackberry, just "workarounds". We had to alter the webworks sdk to make the garbage collection more aggressive to stop the app running out of memory all the time. But if other webworks apps are running on the handset and haven't had this GC tweak you will still get grief with memory.
Don't know if phonegap is any better than this but it'd have to go some to be worse than webworks.
If you want to do a webworks app keep the design simple, package all the graphics and assets in the deliverable (we were trying to get icons from an api but have ended up storing them base64 encoded in localStorage) and get it onto a handset asap so you don't waste time adding features that the handset can't cope with.
To sum up, webworks is pretty poor.
PhoneGap : is an application with a webview control that renders your HTML5 and JS. PhoneGap has diferent versions or say release for different platforms like Android, iOS, BB, WP8 etc.
WebWroks : is conceptually the same thing as PhoneGap just that it is owned and developed by Blackberry (Previously RIM) themselves.
Also one most important thing in the context of the question is that, for Blackberry Phonegap uses WebWorks as its base, that is why while developing PhoneGap Apps for blackberry you need to download WebWorks SDK first, the build process is also the same as WebWorks so the benefit of using Phonegap for balckberry is that the same HTML5 + JS Code that you used for say Android will work on Blackberry as well.
However BB OS 7 and below do not have the best WebView Control, BB 10 and playbook are MUCH MUCH Better.