Recently I created a desktop app with Codename One, that through REST calls implements the backend of a website. Since the graphics were relatively very simple, I could use includeNativeBool: false; and create the graphics from scratch, in order to have the desired graphic look.
Soon I will have to make another desktop app with Codename One, both for Windows and MacOS. In this new app, however, the graphics will be more complex and I don't think it's a good idea to create it from scratch. I wish I could use includeNativeBool: true; and have iOS graphics as a starting point (both on Windows and MacOS). Is it possible?
Note that when I tried to use the desktop.theme build hint it didn't work, but maybe I didn't understand how to use it.
You need to pass a theme file to the desktop.theme build hint. So just download the native iOS theme and place it under your native/javase directory. Then set the build hint as such: desktop.theme=iOS7Theme.
Related
I'm using DesktopAppConverter to convert my WPF application into a windows store compatible app. Right now I'm able to get the AppX built but the problem is to do with my application assets.
At the moment, DesktopAppConverter is taking my existing Icon (which looks great in WPF) and using it to somehow create all the different Assets at different resolutions for the UWP app. The icons it creates are coming out looking terrible, really blocky and clearly upscaled.
The way I'm looking at it is that there's 2 options.
1 - I specify a really large Icon file in my WPF app that might somehow end up being scaled better inside DesktopAppConverter. The problem here is that with a large resolution Ico file, I end up with a crazy large file (Ico's don't compress very well from what I understand).
2 - I specify a folder of correctly scaled assets (created using UWP Tile Generator) when building through DesktopAppConverter. This is what I'd like to do. I don't really want to be tweaking my Assets every time.
The 3rd choice is the one I'm heading towards, but don't really want to do. It involves building with AppX, then replacing the assets, then using MakeAppX, then re-signing with the SignTool. All of that seems really unnecessary, so I'm hoping someone from MSFT can let me know I'm missing something fundamental.
Thanks.
The easiest way to handle the visual assets for your app package is to use the package manifest editor in Visual Studio 2017.
To use it for your converted app, create an empty UWP project and add the output of the conversion (incl. your appx manifest) in this project. Now you can use the editor to manage the visual assets, build your packages for store submission and much more.
Here is a document that describes the process:
https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-packaging-dot-net
Thanks,
Stefan Wick - Windows Developer Platform
I was asked to develop a software in vb.net and one of it's features should be the possibility to take photos on a tablet PC. I already played around with the MediaCapture API which returns me a photo, but as it seems that it's not possible to show a preview or anything else outside of ModernUI apps. It's just pure photo capturing.
I thought for a little while how this problem could be solved. I got some inspiration from my Android phone then. My idea was to call some sort of API to open up the regular Windows 8 camera app in ModernUI mode, let the user take the photo and then receiving that through a "return value", just like you usually do it in Android apps.
Now my question is, if there is a way to start up the Windows 8 default camera app, let it take a photo and receive that back into my WPF desktop application.
I could develop my software as ModernUI app as well, but I never did that and it also seems like you must publish it over the web store then, but I only want to use that inside my company.
My other (simple stupid) idea would be to ask the user to open the camera app by himself, take some photos and come back to my software later. I could then receive the images from the folder they were stored in. I guess that would work as well, but I don't really like that idea because it's not very intuitive and seems just stupid.
If you have an idea (or an alternative), I would be really happy if you could share it with me.
Thanks in advance!
Unfortunately, there are no .NET classes that allow you to access a webcam or integrated camera on your computer. This means that you have to take a look at the native Windows API and call it from your application. I cannot point you to the right methods that you have to use, as I just have used Microsoft Media Foundation to capture a continuous stream of images from a webcam and encode it to a video file.
There are some sites that encapsulate this native functionality in .NET classes, but I don't know if they are good or not:
http://dotnet.dzone.com/articles/using-webcam-wpf-application
http://www.yiigo.com/guides/vbnet/how-to-process-image.shtml
(just google for more if you'd like to).
In Windows Store Apps, this task can be performed relatively easy with the media capture API you've mentioned. You can also side-load Windows Store Apps if you have Windows 8 Pro or Enterprise - then you do not have to publish your app in the Windows Store.
If you have any further questions, please feel free to ask.
I have some apps developed using Xcode4.
When opening the projects and build them for the 5 simulator using Xcode5, most of the apps will look iOS7 style when built for 5 simulator while some still looks iOS6 no matter what I do
The apps are pretty much the same so I do not understand how to decide myself which style it is going to be.
Looking at the settings I do not see any difference.
The app which is built as a iOS6 like style seems not possible to change to iOS7 style, and some apps are built as iOS7 style as default and is not possible to change to iOS6 style using Xcode5.
Please help!
Depends, most of the standard UI elements are redesigned in iOS7 (UIAlertView for instance), you can't do a lot, if you want to keep the ioS6 look you should rebuild all these components by yourself.
Elements that adhere to the appearance proxy can be customized to look like pre-iOS7, but it will be a hard job.
In iOS7 you also have another "problem" to manage, by default all views are full-screen, this is simply to solve if you deploy only on iOS7, bit harder if you deploy for prior iOS7 and iOS7.
There i a way around... download the 4.6 version of xcode ance deploy only on iOS6, most of the UI elements will maintain the same aspect, it seems that Apple still accept <=iOS6 binaries.
How would one go about porting an app built with Android SDK to Codenameone? The objective is to port to multiple OS.
I suggest checking out the Android trail in the Codename One website http://codenameone.com/android.html generally you would need to rewrite your UI and networking code. Adapt to a smaller subset of Java functionality etc.
You could keep most of the business logic intact though. I would suggest starting with a GUI builder application and some of the How Do I? tutorials just to get the UI right then the rest should be easy.
I have a silverlight application, now I want make it run as a mac OSX app, perhaps aiming to sell on app store. Since I'm completely a newbie in mac developing, is it possible to make this silverlight app run like a native app?
Maybe there is some way to make a browser shell, and embed that silverlight on a html to show it. is there any way make it more native without a browser control, and I want to disable the right click "silverlight" popup.
More over, since silverlight cannot access local file system directly, any good idea to do this? First came into my mind is put a webservice module in the app, so that this app acts both client(silverlight) and server, and then process the local file on server module.
The most you can do is have it run as a Silverlight Out Of Browser application (see a bit more detailed explanation here). This mode is pretty much like running in a chromeless browser, however it is still running in the same sandbox and you have very limited resource access.
Apps running this way will definitely not have the native OS/X app feel, neither will they be started similarly and you won't be able to sell it on the Apple App Store.
If you want to target Mac desktops and deliver a native experience I'm afraid currently Objective C or a framework on top of that is the only viable choice.