I'm working on combining Unity Webgiel with Tizen.
The device I use is a Smart M8 monitor.
My order of work is
Build Unity WebGiel
Creating a Tizen Web Application (Smart TV 6.5)
Overwrite Unity WebGel file on Tizen project (Index.html changed)
Build WGT
Convert to TMG file
Install Tizen OS
It worked fine when running the Tizen Web Simulator Application (Samsung TV) in Tizen Studio.
But when I ran it on the Smart M8 monitor, the screen blinking occurred. This problem did not occur in the Tizen Web Application basic project.
What I'm curious about is
Is there a way to solve the blinking phenomenon?
I want to know how to WGT Unity WebGL, not how to overwrite the webgiel file on the Tizen project.
Please answer me
My order of work is
Build Unity WebGiel
Creating a Tizen Web Application (Smart TV 6.5)
Overwrite Unity WebGel file on Tizen project (Index.html changed)
Build WGT
Convert to TMG file
Install Tizen OS
The screen blinking phenomenon can be seen when there are too much overhead on GPU due to heavy WebGL commands.
I think this phenomenon only happened on the smart monitor, because emulator could use PC's rich GPU resources, whereas smart monitor suffered from the limited GPU resources.
In conclusion, to answer your question 1, you need to reduce the complexity of your app in order to prevent the blinking issue. Hopefully a future Tizen version will fix this issue.
Related
I'm planning to develop an app for Android using Qt Quick Controls and an Android Emulator. The same set of components is said to work on iOS. Thus I'd like to build the app for iOS as well.
Unfortunately, Qt for iOS is only available for Mac.
I don't own any Apple or Android device. I'm using a computer running Linux.
What would then be the best way to be able to build the app for iOS (and test whether everything works as expected; most testing will take place in the Android emulator)?
If any more information is needed, feel free to ask in the comments.
I'm a longtime Windows desktop developer (25+ years) who has been doing native Blackberry 10 mobile development for 18 months. For my next app I have to hit as many mobile platforms as possible and have decided on Cordova (NOT PhoneGap) for the job.
I have successfully built and deployed a test app on Blackberry 10 and Android with the Cordova CLI. Now I need to get the workflow for iOS figured out before I start actually coding the real app so I can test on all platforms as I go along. I have OSX Mavericks running in a VMware VM from Windows 8.1 and have Xcode installed on OSX. I'm only slightly knowledgeable in OSX, but I know that I must use it to build for iOS. What I'm trying to figure out is how much duplication of effort I have to expend within OSX to build for iOS. I suspect the challenges would be the same if I was using a physical Mac to package and test for iOS so hopefully there are others out there who have figured out the cleanest way to do this.
Can I use Cordova on Windows to create the iOS project and source or do I have to create a duplicate project platform using Cordova on the Mac and keep duplicate source code there too? If I can do all that from Windows, do I just copy it over to Mavericks after every Cordova build and use Xcode to package and run it in an emulator? If anyone out there is running OSX in a VM for this like I am, is it possible to map a host path into OSX so I don't have to recreate the platform source at all after I build it from Windows? I'm assuming there is not way to automate the whole thing from Windows Cordova like there is for the Android and Blackberry platforms, am I wrong?
My desire is to do ALL coding in Windows and only use Maverick for the final bundling for iOS. After 25 years of pro development I'm not used to being a complete newbie and I'm not crazy about it. LOL
Learn Mac OS X. I know you feel out of sorts in this environment, but honestly -- it's not that difficult. In fact, I made the transition from Windows 7 rather than upgrading to Windows 8, and I was comfortable very quickly. (Far more comfortable than I am with a Windows 8 laptop others in my family use.)
Remember that Mac OS X is a Unix underneath (BSD). This means that if you are in any way familiar with Linux or Unix but are put off by working with the Mac GUI, you can almost always fall back to the terminal. (In my not-so-humble opinion, Mac OS X makes for a very nice *nix machine!)
Your VM should be able to share drives across the network, just like it would if it were a real machine (Apple supports SMB reasonably well). This way both environments could point to the same Cordova project without having to worry about copies. (You can copy the projects around, but it would be easier, in my opinion, just to share across the network. Less risk of accidentally doing something stupid.)
The only things that require a Mac are:
Creation of certificates / provisioning profiles (and there are ways around this on Windows, but it is not supported)
Submission to the app store
Remote debugging using Safari (You can use Weinre to come close, but it doesn't support breakpoints and such)
Local compilation of your code (and there are other toolchains available that do this on other OSes, but again, not supported by Cordova).
Running the app in a simulator
The above means that you can develop your app on Windows and only run to the VM for compilation / submission. With the advent of the Phonegap Developer app (http://app.phonegap.com), you can skip the (re)build step during development and testing as well (as long as you use only core plugins).
Note: I know you indicate you are using Cordova and NOT PhoneGap. What's nice is that, ATM, the Phonegap Developer App works just fine with Cordova projects (whereas PG Build often requires config.xml to be moved and plugins to be handled differently). It does require the PhoneGap CLI to be installed. As long as you are using core plugins, it definitely saves time by eliminating the rebuild steps.
The Cordova project can be created on any platform -- but I know there was a time when adding the iOS platform to your project (cordova platform add ios) would check that all pre-reqs were met, but I'm not sure if that is still the case. It can't hurt to try. But if it is required, use a network share and add the platform on the VM. Keep in mind that the platforms should be thought of as build artifacts -- your app code should live in the root www, which doesn't depend on the added platforms.
Do not rely on the iOS Simulator to tell you anything about how the app works or performs on a real device. The simulator has all the power of your desktop (processor speed, memory, etc.) and lacks many on-device features as well. I suspect the visual performance of the iOS Simulator will be horrid, since it will rely on the GPU as routed through the VM. (Frankly, it's not always great on a real Mac.) You really, really, really must have a real device to test on. (Again, the PhoneGap Developer App can ease the pain of repeat deployments for testing.)
I am contemplating developing iOS apps use Delphi XE4 with iOS. In my research I saw MacInCloud, http://www.macincloud.com/features/tools/tools
Does anyone have practical experience with this? Can I hook up my Windows/Delphi/similar development tool to MacInCloud/xCode for cross compiling (to obey licensing terms) and have the app debugged on my iPhone?
Maybe over time it would be beneficial to buy an iMac, but if I could start creating apps without it would be great.
I recently tried exactly that with MacInCloud. XCode and Delphi XE4's PAServer is now automatically installed by MacInCloud so I had few issues hooking up my Windows and Delphi environment.
What I found was that running and debugging in the iOS simulator on the Mac in the cloud worked fine. However as my upload speed was quite slow a compilation took some considerable time. Each compilation seemed to require an upload of about 17MB for the app and another 50MB for the debug symbols.
There is no way of plugging in your iPhone into the mac in the cloud and MacInCloud therefore recommend that you use a further cloud provider (TestFlightApp.com) to deploy the app to your device. I couldn't test using the TestFlightApp service as I have not signed up for the required developer account with Apple and so cannot deploy to physical devices at all.
All in all, if I was doing serious work I would either buy a Mac or pay for faster upload speeds but despite that I found it an very educational experience.
Good luck with TestFlightApp. That is one of those great services we use to have but not anymore. It use to work at one time but has fallen in great disrepair and been neglected.
Even if that did work, you would go out of you mind if you was working on something that can only run on the device. Not all iOS features work on simulator, like in app purchase for instance.
Where with a real machine at hand it deploys right to device almost as fast as simulator. Just a few seconds longer. Doing it this other way would take 15 minutes or more and require many steps of your interaction. You will forget where you left off in your code by that time.
We have a couple of Blackberry apps and are now trying to prepare them for BB 10. These apps are made in Java via Eclipse and/or RIM IDE tool. However, when I went to https://developer.blackberry.com/platforms/bb10, I saw that there is no even a mention of Java SDK. Take a look at image below.
So how am I supposed to update Blackberry app to BB 10? Any ideas?
You have to decide what to do with your applications. If you have an Android version, one option is to repackage the APK to a BAR using the provided tool set so that it will run under the Android player. There are many good Android applications that provide an acceptable or even good user experience this way. Another option is to port your BlackBerry Java application to Android (if there is no existing Android version) then package the Android version for the player. This would also allow you to market the application to Android users. The final option is to port the BlackBerry Java applications to the Native SDK, Cascades, HTML5 or Adobe Air.
The best way forward depends on how tightly integrated into the BB10 system you want to be. While there are facilities provided in BB10 that are the equivalents to those is BlackBerry OS, there have been significant changes required to enable the improvements everyone wants to see on the new platform. If you see BB10 as a significant part of your future business then porting to Cascades would be very worth while.
We have a fairly simple mobile application, completed for iPhone and Android that does the following:
queries a web service to verify the user's account information
display an animation to show that the user, in fact, has a valid account
We got the application working very quickly on a PlayBook by using the Android version.
Now the customer has asked us to explore getting it to work on other BlackBerry devices.
None of us know that much about BlackBerry, and the main source for our question returned from google searches (http://us.blackberry.com/developers/choosingtargetos.jsp) comes up as 404 page.
According to this chart there is still a wide variety of devices in use. Which ones does it make sense to target?
Thanks
I had posted an answer last year about this here on stackoverflow, but as you noted, that link has recently broken.
The only thing I've found that's similar is this BlackBerry developer page. It shows, for example, that paid apps are being purchased by devices that are about 97% on OS 5.0 and above.
From what you've told me, I don't know that your app is going to be that different on different devices, aside from maybe the obvious smartphone vs. Playbook difference. Different devices certainly have different screen sizes, so you'll need to make sure your UI is coded to handle that gracefully.
If you guys are new to BlackBerry, you might want to stay away from OS < 5.0. There are some things in prior OS versions (e.g. location services / maps, browser, and networking) that are a little tough to work with, and with such a small percentage of paying customers still on OS < 5.0, it probably isn't worth it to you.
So, I guess I'm recommending that you target specific OS levels (e.g. 5.0+). That will be a bigger driver for how you build your app, than a specific set of devices. This is because each OS version adds more and better APIs to use.
Once you've decided which OS to target, then you should download the SDK for each major OS. For example, if you use the Eclipse BlackBerry plug-in, you can install the 5.0 SDK (aka component pack), the 6.0 SDK, the 7.0 and 7.1 SDK.
Once you have those SDKs installed, you'll then have a bunch of simulators (each SDK has a simulator folder). Run your app on all those simulators, and that'll probably be a good start.
Of course, there's no substitute for running on real hardware, too, but if your app does mostly standard things (not interacting with hardware sensors, just displaying web pages, and making HTTP requests), the simulators should give you a pretty good test environment. They certainly will give you all the screen size configurations.