I decided lately to move from Eclipse ADT to the latest AS version.
The first weird thing that I've noticed is that when I create a new project, it is always based on the Android support library even though I selected the minimum SDK to be level 19.
What is the reason for that?
Is there a way to configure it otherwise?
The reason for this is mainly backward compatibility. Right now, you may want to make your app for API19+, but later you may decide to lower it a bit down to support more devices, and you shouldn't be having problems with that, if you use support library.
There's also the thing that support library gets updated much more often than Android core library, therefore, if you base your project on it, it should be pretty much bug free.
One more thing, if you extend activity compat for example, the activity checks what version of Android you are currently having on your device and uses core features automatically if available, so it's good for you in many ways to use support library :)
Related
MPS enables me to build standalone IDEs (see https://confluence.jetbrains.com/display/MPSD34/Building+standalone+IDEs+for+your+languages), however Windows builds would definitely need a JDK/JRE. The users get confused with installing Java, etc.
Are there "pre-built" JDKs compatible with MPS (IntelliJ platform)?
What are the approaches to update the bundled Java? IntelliJ platform does have an updater, however does it support updating the Java runtime? The updater is Java-based, so I wonder how does it update Java runtime when using the same runtime.
Can something like JetBrains Toolbox to manage updates of the "third-party" MPS-based IDEs?
PS. I'm using for MPS 2017.3, mbeddr if that matters.
I'm not exactly sure if the are publicly available but you can check JBs teamcity at teamcity.jetbrain.com where all their open source stuff is available.
The updater for intellij performs incremental updates to the jar files. It is not open source and it usually only used to do small updates. If there is a major update like new platform with a bunch of API updates it is not used and the user has to download complete new installer. In MPS the incremental updater is not used. So each MPS updates is complete new IDE to be downloaded by the end user (or JB toolbox).
I don't know how the JB toolbox works but you can use MPS/IntelliJs normal update mechanics to notify users about updates to your custom IDE. In the branding you create for your custom IDE there is field where you can point it to a update location. Which then serves a xml file with the update information. The format is pretty straight forward. Here is a sample. Your IDE will check on start up or at least once a day if an update is available.
I am developing Windows Store app using Visual Studio 2013 with update 5 in Windows 8.1, but now we move on to windows 10, and issue arise is responsive in XAML.
I want to know is it possible to design Windows Store application behavior is responsive with existing Visual Studio version 2013?
I explore it how to responsive Windows Store app, but Visual Studio gives this in VS version 2015 and 2017 like relative panels properties, and triggers etc. So, but I can do this in Visual Studio in 2013 version.
So much has changed since Windows 8.1...
You have options on how to go proceed that would depend on many factors - like your resources (time, people, money...) or the composition of your user base.
Your best bet might be to build a separate UI for Windows 10 and reuse mostly just the view models. Possibly simply move the 8.1 version on a back burner and only fix problems and continue working on Windows 10 version separately. This would save you from having too many test dimensions in your code to do API checks etc.
The careful and cheap option is to only add specific new features lighting up on new versions of the OS using API checks.
If what you're looking for is using relative panels and triggers while staying on VS 2013 - well, you don't. The thing is though - relative panels and triggers are only there to make things slightly simpler to do. You can still achieve similar or same results in Windows 8.1 with some custom code.
You can use separate templates for your UI and switch them when the size changes.
You can handle size changes in code behind and rearrange elements and properties from there.
You can build a custom VisualStateManager and/or custom panels that do the same things as you get from the responsive design features in Windows 10, although that's possibly writing a lot of throwaway code that you wouldn't need anymore as soon as you could move to newer versions of VS and drop support for older versions of the OS.
I am trying to build a project using NDK media sdk, but I need it to run on older phones too (to support 90% of the market...). Now, I am able to include the libmediasdk.so & libOpenMAXAL.so manually, and it seem to link properly, but I am not sure this is a correct practice.
Moreover, the libraries (libmediasdk.so & libOpenMAXAL.so) are expected to be available on the target device, so unless I do copy them manually to the project/libs/arch-arm the application complains libraries are not found.
Have I gone too far ? :) hope not..
You can write code that optionally uses the new native media functions (libmediandk.so), but you can only use it on Android 21+. So if you want to support older android versions, you must make this codepath optional, allowing it to fail cleanly on other devices where libmediandk.so doesn't exist.
If the MediaCodec APIs are optional within your app and you are ok with them only being available on Android 21+, you can just make sure you build this into a separate lib (like libyourapp-media.so), and be ready to handle the case when System.loadLibrary() for this library fails.
However, if you want to use other native code components in your app, there's a few gotchas you need to know. If you build your app targeting android-21 and your native code uses certain functions (such as atof), it will only run on android-21 or newer (even if code using the function atof would build just fine for the older platforms). The reason for this is that the atof function didn't exist before, and calls to it were redirected to strtod. If you build your library targeting android-21, it will actually do the calls to atof instead, which doesn't exist in the older platform versions. This also goes for quite a number of other functions, not only atof. See http://b.android.com/73725 for details on this.
Therefore, if you want to use the new native media APIs in a library that should be loadable on older versions (except for the native media APIs that obviously won't work on older versions), you need to build your native components targeting an older android version. You'd need to duplicate the media/* headers from android-21, but instead of linking to libmediandk.so (-lmediandk in LOCAL_LDLIBS), you'd need to load this library at runtime using dlopen.
If you need to do the same on older platforms as well, you should use the MediaCodec API in java (which you can call via JNI). Then, there's little point in doing all of this extra work just to use the native version of the API on Android 21+, when you can use the java API on all versions (it works from Android 16, and more reliably since Android 18).
I am wondering what level of support the latest MonoTouch has for using SQLite. The closest information I can find is this article here which referes to limited support in v1.2 however it concedes that you may run into run time errors while using this.
This is what I found on the Xamarin website: http://docs.xamarin.com/ios/Guides/Advanced_Topics/System.Data
This really scares me. Is there any documentation out there indicating what current level of support Xamarin has for SQLite?
I can't speak about the changes in System.Data support past that article, but I think it's quite common for folks to use csharp-sqlite, or better yet sqlite-net instead. Csharp-sqlite is an independent port of SQLite. And sqlite-net is "better yet" in the sense that its a minimal library where you can drop a single file in your project and use it to support sqlite on the various mono platforms. Yet it has nice features still such as "strongly typed queries" due to reflection-based ORM. So if you don't need a full Sqlite driver its a good option.
Greg Shackles did a nice seminar on x-platform dev with Monotouch/droid back in April where he covers these and other libraries: http://blog.xamarin.com/2012/04/25/cross-platform-mobile-development-seminar/
This link is outdated, it's about MonoTouch 1.2 and the latest MonoTouch's version is 6.0.
I'm using Sqlite with Vici CoolStorage in two apps on App Store: easy and no problems at all. I've never see any runtime errors using Sqlite.
When using 3rd party libraries/components in production projects, are you rigorous about using only released versions of said libraries?
When do you consider using a pre-release or beta version of a library (in dev? in production, under certain circumstances)?
If you come across a bug or shortcoming of the library and you're already committed to using it, do you apply a patch to the library or create a workaround in your code?
I am a big fan of not coding something when someone else has a version that I could not code in a reasonable amount of time or would require me to become an expert on something that wouldn't matter in the long run.
There are several open source components and libraries I have used in our production environment such as Quartz.NET, Log4Net, nLog, SharpFTPLibrary (heavily modified) and more. Quartz.NET was in beta when I first released an application using it into production. It was a very stable beta and I had the source code so I could debug an issue and there were a few. When I encountered a bug or an error I would fix it and post the issue to the bug tracker or author. I feel very comfortable using a beta product if the source is available for me to debug any issues or there is a strong following of developers hammering out any issues.
I've used beta libraries in commercial projects before but mostly during development and when the vendor is likely to release a final version before I finish the product.
For example, I developed a small desktop application using Visual Studio 2005 Beta 2 because I knew that the RTM version would be available before the final release of my app. Also I used a beta version of FirebirdSQL ADO.NET Driver during development of another project.
For bugs I try to post complete bug reports whenever there's a way to reproduce it but most of the time you have to find a workaround to release the application ASAP.
Yes. Unless there's a feature we really need in a beta version.
There's no point using a beta version in dev if you aren't certain you'll use it in production. That just seems like a wasted exercise
I'll use the patch. Why write code for something you've paid for?
There's no point using a beta version in dev if you aren't certain you'll use it in production. That just seems like a wasted exercise
Good point, I was also considering the scenario of evaluation of the pre-release version in dev, but I supposed that taints the dev -> test/qa -> prod path.
I'll use the patch. Why write code for something you've paid for?
What if it's not a commercial library, but an open source one? What if the patch to be applied is not from the releasing entity (e.g. your own patch)?
I use:
Infragistics (.NET WinForms controls)
LeadTools (video capture)
Xtreme ToolkitPro (MFC controls)
National Instruments Measurement Studio (computational libraries, plotting, and DAQ)
I've found significant bugs in every one of these, so I try to limit their use as much as possible. Infragisitcs is pretty good for what it is, and National Instruments is by far the best, although quite limited. I would avoid LeadTools at all cost.