We have a large game built with Flex SDK 4.0.0, using Flex 4 as the GUI framework and (largely) PureMVC as the architectural framework.
Since we need to add right-to-left text/layout support to the game in the near future and the layoutDirection property is only available in Flex SDK 4.1.0 or later, we obviously need to change the SDK with which we build our project.
Are there any known pitfalls and issues that we could run into when making the switch? What are the things to keep a close eye one (ANT tasks? namespaces? custom components? charting?) because they could break during the migration?
We finally decided to make a bigger step and go directly for SDK 4.6.0/FP11.1 and while doing so we will be refactoring lots of stuff anyway.
Related
I have an application that we are going to upgrade from .net framework 4.6 to .net 6.
However one class library has to be run in .net 5 because of limitations in a Linux version that we have to use.
So I wonder if it is possible to use the .net 5 library with .net 6?
I tested experimentally on a simple case. The .NET6 app referencing .NET5 library could be built without any warnings or errors and ran without runtime problems:
Some related quotes from Microsoft Docs:
If you're using libraries to break down an application into several components, we recommend you target net5.0 or net6.0. For simplicity, it's best to keep all projects that make up your application on the same version of .NET. Then you can assume the same BCL features everywhere. (...)
To me, this sounds like a good practice to have everything on the same version (5 or 6), but not like a strong requirement.
I'm not 100% confident about edge cases, however. I couldn't find any confirmation of compatibility. At the moment, I would hesitate running a complex production app built from components mixing 5 and 6.
I´m evaluating differents mobile frameworks, and I think that nativescript is a good option. But I don't know if exists limitations on the development process. For example I had limitations on the styling (and that's not so important), but I want to know if in the future I can have a limitation and can´t use some native feature or external library.
Thanks!
I have been using NativeScript since v0.90. I have written multiple apps and over 40 plugins for NativeScript, so I am very familiar with the ins and outs of the platforms.
This post is features as of v6.50.
I can think of only a couple limitations;
Tooling sometimes leaves a lot to be desired, however using the IDE's supported make this better than the Native CLI in a lot of cases.
Sometimes errors aren't always propagated back from the app to the screen/ide -- so you have to do things like "adb logcat" to see the full error log to see the error that got filtered out by the CLI.
Native Services (i.e. background services) --- This is much better written as native code. The NS runtimes take memory while running; so a service you typically want as small of a memory footprint as possible -- I would not use anything but Java/ObjC for a background service.
OpenGL on android needs to run in a separate thread, NS by default switches you back to the main thread when returning from any native calls; this basically kills direct NS opengl calls. However, it is actually better to create any OpenGL stuff in Java or Kotlin anyways; and then have NS call into your native code that handles all the rendering, so this is more of a minor annoyance.
Beyond that I can't think of any "real" limitations; you have full access to the native platform and can actually style any control as long as you know how to do it via native calls; if for some reason the control doesn't support the normal css styling. I & others have used many Android and iOS libraries in our apps. You can easily reuse native android/ios components you have full access to anything out there that is available to a native iOS or Android app.
You can look at https://plugins.nativescript.rocks for a list of all the plugins in the NativeScript community.
I have been developing with Nativescript for some time now, and while finished product (application) is more than decent, the process of development is really painful. The primary reason for that are frequent bugs in Nativescript platform itself, and it's official plugin for VSCode.
I am currently working on Nativescript 2.0.0 and have been trying to update to newer versions since they came out, but there were always some errors, ether with Node, or with Gradle for Android, and that is just one of many problem examples I face with the platform. I wish they improve it in the near future.
For now native apis are fully accessible from JS but if you want you can do some library in native languages and call them from JS code too, about external libraries it depends if you mean native libraries or JS ones, but there quite many options/plugins done in JS code using some native libraries but in case not as JS plugin you can do it yourself with native libraries
Community support is low compared to other frameworks available in the market. This should improve as people adopt the framework. I see that as a limitation for now.
And Yes, Debugging is indeed a limitation.
Nativescript is the best cross-platform solution in my opinion, but like the others stated there can be limitations. Besides background services, accessing the hardware CAN be a bit tricky. I have been using it to work with BLE devices though, and once you understand how to interact with native APIs, it isn't so bad.
I've written one NS app (core).
Some of the cons are:
performance - loading and also run-time. I'm replacing an Android native app with a NS app (because it's cross platform) and few customers have complained that the new app is slower and jerky...I agree.
bugs in NS core. I think that they've spreading themselves too thin. They need to get their core product stable and improve it (i.e. make it faster).
plug-ins varying quality with minimal support. Here NS could curate a few important plug-ins and make people pay for it.
Yes it's free - but that's not a huge issue for me - I'd prefer to pay for a more polished product.
At the end of the day - the product works - have my app in the app-store and look forward to future improvements.
I've created an iPhone game which utilizes some code from an old version of the Cocos2D iPhone game development framework and I've got a wee bit of a problem running it on iOS 7.
The version of Cocos2d from which the code was used was probably 0.98.
The actual class is called QuadParticleSystem (in newer versions it's been deprecated by CCParticleSystemQuad).
The actual issue is that the game runs fine on iOS 6 and below. It even runs fine on iOS 7 if the deployment target is set to iOS 6.0 and SDK version set to 7 (at least when put on the device directly using XCode).
The problem is that when the game is uploaded to the appstore, Apple seems to strip out the whole iOS 6 compatibility thing and the particle emitters fail to show up among other things like alpha transitions, invisibility etc.
(They initialize correctly and everything, but they simply DO NOT render).
I've considered (and tried somewhat) upgrading the Cocos2D version, but due to the old third-party frameworks I've used for other things there is a hell of a lot of linking/dependency/deprecation errors which could take forever to fix (if it's at all possible, which I doubt) In other words, I've wasted too much time on the project already and am looking for a quick fix.
If no one knows any solutions could anyone at least direct me to docs where I can see how to create/insert a new particle emitter system in the existing code?
I've thought about using SpriteKit's native emitter system, but I don't know how to incorporate it within the current code (as I've never had dealings with SpriteKit) and am not sure if it's even possible.
I've also thought of maybe upgrading the GL ES framework within that old version of Cocos2D just in case Apple have killed off some functionality of older versions of OpenGL. Then again that could take a while.
I'm trying to get into mobile game development with Xamarin; I am using OpenTK for rendering.
My plan is the following:
1. Make a shared library that is actually the game (and has all openTK code).
2. Make a a runnable project for iOS and Android that handles platform specific stuff (e.g. popping up alerts) and uses my shared library.
Is this possible with openTK? Does it have exactly the same API on iOS and on Android, just the linked library is different? If yes, how to avoid code duplication?
Your approach sounds very reasonable and will work with a little bit of effort.
The reason is that Xamarin.Android and Xamarin.iOS were forked from an alpha version of the library and have evolved slightly different APIs. Much of the OpenGL ES binding is identical, but some functions have annoying (and unnecessary) differences that you will need to #ifdef in your shared library.
The good news is that the Xamarin fork of OpenTK has now been open-sourced, so we are actively working towards a solution. I already have a private build of library that exposes an identical OpenGL ES API between Android and desktop platforms[1] and I'm working on fixing the differences between the iOS and Android versions.
You can follow the development of OpenTK in the official github repository.
[1] You can execute OpenGL ES code on the desktop using ANGLE or the ARB_ES2_compatibility and ARB_ES3_compatibility extensions. This makes OpenGL ES the first graphics API to work across all major platforms (Windows, Linux, Mac, Android, iOS - and hopefully WinPhone in the future.)
I'm a developer, with years of experience in C# as well as Java.
I have developed a few ADT projects for my Nexus One Android 2.23 phone.
I am considering further mobile development and I heard of Mono for Android/iOS and Xamarin. At first I thought Mono would recode to Java, but now I understand that it compiles to native C code and runs over mono libs.
So I was wondering how much bloat does this add to apps, as I believe size of download is directly linked to number of downloads (I myself sometimes don't download something due to it being > 1MB)
If there is someone here who uses Mono I would love to hear from your experiences.
I understand there is a Visual Studio 2010 Plugin for Mono. Do you recommend it?
So I was wondering how much bloat does this add to apps, as I believe size of download is directly linked to number of downloads (I myself sometimes don't download something due to it being >1MB .... )
Monodroid apps are usually somewhat around 5 Megabytes (if Linked) because the runtime is embedded in the app.
If there is someone here who uses Mono I would love to hear from your experiences.
All in all i'm pretty happy with Monodroid. Java tutorials on Android are easy to translate or if too big you can create Bindings. I've only done one project on Mono so my experiences are limited but thus far i've expected nothing that would make me regret my choice. On the other hand, if you're familiar with Java (and like coding in Java) their is no reason to switch over except for Cross Plattform apps (see Monocross).
The VisualStudio plugin is necessary to develop in VisualStudio. The new version comes with a Layout Designer like the Android Eclipse plugin. I'd recommend you download the trail version from Xamarin and try it (the trail has no expiration date, it lets you only deploy to an emulator)