Handling custom translation in Android apps - Java for Android App Development

I just want to share my experience with translating my app.
These were the requirements:
APP should be able to load custom translation XML (strings.xml) so that translator could check his/her translation without waiting for the developer to release a new version
User-selectable app language
Forms should respond to language change immediately
Full RTL support
Android public libraries are extremely programmer-unfriendly in this respect: a good solution is impossible because Google really tried hard to make this impossible. I have explored more than 20 different options trying to find a hole in their final / non-public maze of denials, but was unsuccessful. The only reason my app supports this almost entirely is because I have custom settings builder (switches were abysmal in original android settings activity) and because the other activities have relatively simple text components so not much code was needed.
Sorry I can't be more help, but I think this current solution is pretty good as it is. I just can't do menus (but I could) and string arrays. Everything else works
Due to Android poor RTL support, some forms just can't be designed such that they would work RTL right away (I found that automatic activity form modification would also be quite impossible), so two copies would be necessary, as evident from this sample activity onCreate code snippet:
Code:
TX.translateLayout(this, TX.RTL ? R.layout.activity_auto__brightness_rtl : R.layout.activity_auto__brightness);
The onResume code simply does the same as onCreate (thus providing immediate response to language change)
Any string can be obtained by calling TX.s function:
Code:
TX.s(R.string.preset_name)
Non-activity code still needs context for translation code to work properly, which is initialized by calling an initialization function at code (service / Receiver, etc) startup.
Code:
TX.setContext(aContext);
Please note that I didn't bother to clean up the code in the attachment. You will need to change the package, log calls and possibly the TranslationLayoutInflater, which currently doesn't support all widgets.
Hope anyone finds this useful. I also think my custom settings dialog fully supporting RTL and using screen space more efficiently than the system provided one. If there's interest, I'll post that code as well.

Related

Implementing a plugin system in my app

Hi all,
I'm new to Android development, kind of a Java noob, but not to programming in general. I'm not looking for code examples, just theory or a basic 'how this is done' in Java/Android. I also hope this will become useful information for other developers heading down this path.
I've had some success creating my first Android app - I apologize for not going into details about the specifics of the app, as I plan to eventually sell it commercially on the market - the question should, however, be applicable to any application using this flow model.
My current goal for this application is to create a 'plugin' type system ( like those used in OpenHome and other apps that allow user-generated plugin-able content / functionality ), to allow for flexibility in both my own further component development, as well as eventually creating an open interface for other developers to use to extend the application.
Currently my application is laid out as follows:
Main UI class
- entry point to the application
- starts the service class to spawn 'spinners' ( data processors )
- presents the user with an (ideally) extendable interface to the service
- binds to the service class using AIDL
Service class
- presents an AIDL interface for communication from the UI process
- creates 'spinners' of various types based on user interaction that process data
- persistent, will run in background, new Main UI instances will connect to the running service and present the currently running spinners.
- extendable via an as-yet-unimplemented plugin interface to add new types of spinners
Spinner classes
- use a generic interface with a handfull of common methods to communicate with the Service class, bubbling up data to the UI interface.
- processes user defined data streams, outputs to a buffer/sink suppled by the Service
Assumptions I can make are:
- the plugin (Spinner) class will always implement / override a group of methods to present to the Service class; ie 'putData()', 'getStatus()', 'start()' and 'exit()'
- the plugin class should always return data to the Service class via a supplied/shared buffer ( short array, for example )
Where I'm stuck at the moment is exactly how to implement extendable classes without those classes being a part of the current code base package. More simply, how do I interface with these classes without knowing their names, methods, etc?
As mentioned, I'm new to Java so I may just be overlooking an already implemented class that handles this interaction. If that is the case, I'd be happy for anyone to tell me to shut up and read the docs, if you can point me at the proper docs
What I really don't want to do is create a 'plugin language' for these external bits, as I feel this could hamper development of fast/functional plugins vs. those written as native Java classes. This would also expose potential security issues, as I'd need to create a public interface to the Service class for these applications to link to. I'd prefer if execution of the plugins remained private / internal to the 'main' application.
I'm already using an AIDL interface between the UI class and the Service class - it would potentially be possible to use further AIDL interfaces into each plugin, but from my romp-through-the-park implementing the UI -> Server communication in this way, I find it cumbersome and difficult to pass any kind of complex data sets/controls. And I'm still unsure how the Service class would actually implement these without inheriting the interface directly.
I've poked around Intents in Android, but I'm having trouble wrapping my head around them/what they're for - it seems it might be possible to inherit the plugins that define themselves as sinks for my applications specific Intent type, but I'm lost in the details of how this works exactly, or if it would even be a viable path for what I'm trying to do. Can new Intents even be introduced into Android?
I apologize for the long-winded explanation of what boils down to a simple question:
How can I implement a 'plugin' interface in my application to allow myself and other developers to extend my app through their own classes?
I've been a Java developer for 10 years or so.
From what I understand the "Android" way, would be intents. I'm still working on wrapping my brain around them too.
However, the "Java" way would be to define an interface (or several) for the plug-in(s) to implement. Then use reflection to identify classes in the classpath that implement that interface.
There are some advanced techniques using custom class-loaders, but researching reflection should get you started; if you choose to go that route.
Thanks for the quick response, I'll take a look at the reflection implementation.
Intents do seem to be the 'way to go' for inter-application communication in Android the more I read about it though - if I can figure out how to pull in plugins which specify my applications 'Intent' dynamically. Intents seem to work really well for spawning a 'dumb instance' of an application - like the browser when clicking a link in another app - when your application doesn't want to deal with that data locally.
Seems a bit more difficult to wrap them around a bi-directional interface between the service and the external plugin application. If anyone's got experience with this kind of thing I'd definitely appreciate prodding in the right direction. Documentation on Intents is confusing at best.

[Q] Some questions about developing

Hi there, i'm new to developing Android Apps, so i have some questions.
1. I know that always have a chance of breaking security on computer world
2. Whats the most secure method to generate a UniqueID? because my app needs to work on china tablets, original tablets, cellphones, hacked phones, etc. I need this for verification of paid things (wait, xda will have a free version ;o)
3. There is any way to encript the program without affecting the performance too much? I'm new to java and comming from C++, so there is any compaction, encrypt, etc? Because if anybody knows the NEW IDA will come with android support.
4. There is any HTML parser on java? Because i need to fetch a html page with httpclient and after i need to parse it to get content... the contect is dynamic (html table with N rows), so i need a parser... or there is any other way?
5. I know how to make a tabed interface, but how is the best way to know the app state? Like it:
App Start -> User Already Logged (Save on SQLite?) ?
Yes = Display app interface and unlock config menu (here is the tabed interface)
No = Display login interface and lock config menu (here is just a relative layout with login bnts)
Thanks in advance.
1: Number one is not a question.
2: Do you mean most secure possible, or most secure practical? Those concerns should be addressed. Most secure would be to have a courier bring the user one-time-pads for every session, but that's not very practical. That said, what is the nature of your ID? Depending on what you are using it for, I would think a few randomly generated bits from some user entered entropy (like touchpad event timing) should suffice.
3: Again, what is the nature of your need for encryption? Do you want to keep it from being decompiled and analysed? If so, you're pretty much out of luck as there is always a way for a dedicated hacker to disassemble the code that does the decryption unless you use some sort of challenge-handshaking algorithm to load the keys at runtime for every session from some secure source but that requires connectivity and user interaction which necessarily complicates the process.
4: The XML parsers available as part of the Android SDK do a pretty good job of parsing HTML if it is clean compliant HTM> See, i.e. the Sax classes:
http://developer.android.com/reference/org/xml/sax/package-summary.html
5: You can use the API included preference classes to save state between sessions:
http://developer.android.com/reference/android/preference/package-summary.html
Note: for general application cryptography information, you still can't beat the venerated Applied Cryptography by Bruce Schneier.
Thanks for the answers.
I just wanna know how the most used programs like rom manager, power amp, titanium backup and whatsapp protect their paid versions, and how they validate it.
Another question that leaves on it is that some programs have a dedicated paid version, and some have just a key that you download and unlock the free version, how they did it? They just check if key is installed assuming that it was downloaded from market?
My uses is just for two reasons:
1.) protect my app as possible from newbie crackers
2.) transmit user information with a secure method to my server. Its important because my app will be used on open networks.
As for UniqueID generating, i just wanna a "unique world global super id" for each user of my app, and it will be installed on cellphones, tablets without phone, tv with android, and all of this.
Also, what to do if html is not well formated?

[SDK] [Library] More languages in your app without app redeployment

It’s just 20 minutes of your time to let users learn and practice languages while translating and using your app.
Android multilingual runtime extension: the Nativer SDK
… is a new app localization technology for Java Android apps that implements dynamic string resource management. It separates the translation from the development process and supports on-the-fly resource distribution, so no app redeployment is needed when adding more languages.
Integrating the Nativer SDK with your app and uploading resources into the translation service requires less than 20 minutes. There is no source code modification required, removing the SDK is easy.
The Nativer SDK uses aspect oriented programming (AOP) with AspectJ; work is done automatically at build time. Tested with:
• Build tools: Gradle
• IDEs: Eclipse, Android Studio and IntelliJ IDEA (SDK on Github)
• +automated integration plugin for Android Studio and IntelliJ IDEA. (AS plugin on Github)
The SDK and the service are free for developers up to 4000 words/apps.
Switch languages with a shake
The Nativer SDK and service adds multilingual features while translating and using apps.
App resources are automatically translated via machine translation and app category specific translation memory. Any user can improve the quality by adding new or voting on existing translations, reporting bad or mistranslations.
All translation work is done "in context": on the smart device while using the app, translator immediately sees how the translated text looks like in its original environment.
Approved translations can be downloaded with one click. The app language can be set independently from the phone language that helps learning and practicing languages.
Built in Klingon
This ease of app localization ensures access for all. Even minority languages will be served properly but without any effect on your budget.
Users prefer localized apps. The multilingual features result in higher usage time and more loyal user base.
We support 70+ languages. Localizing your app into 70+ languages has a big impact on the Served Available Market and may bring you more users.
How it works?
What you have to do?
• Build the SDK in your app (Github)
-> With Eclipse it takes no more than 20 min
-> With Android Studio it takes only 1-2 min (AS plugin)
• Publish your app
• Follow the progress and enjoy the result
How translation happens?
App resources are automatically translated via machine translation and app category specific translation memory. Any user can improve the quality by adding new or voting on existing translations, reporting bad or mistranslations.
How users get translations?
Since translation is separated from the development process and users get on-the-fly resource distribution, so no app redeployment is needed when adding more languages.
If you want to control translation
You can override the automated translation and distribution process if you want:
• Exclude already translated resources from translation and distribution process
• Exclude any language by any reason
• Determine localizations to be published or not by language
• Translation review by string
We prepared a tool window for easier usage and to track how translation goes on. It's also in IntelliJ plugin repository http://plugins.jetbrains.com/plugin/7637?pr=androidstudio

[Q] How to hide an algorithm?

Hi,
I would like to add some specific calculations to my app but I want to keep it safe. How can I do it? Maybe I should use C++ and link it from code in Java?
There is a so called proguard feature for building apks which obfuscates variable, class and method names but maybe this won't meet your security visions
--------------------
Phone: Nexus 4
OS: rooted Lollipop LRX21T
Bootloader: unlocked
Recovery: TWRP 2.8.2.0
I'm using ProGuard, but it is not hiding algorithm into binary code. I'm gonna need more advanced solution.
I think that, unfortunately, you can't. There will alway be a way to find out the code you've written.
If it's really very important, one of the best solution should be to create a server and execute you algorithm on it, but the user will have to be connected to internet to use your app and it could make some people leave it.
Jorexapps said:
I would like to add some specific calculations to my app but I want to keep it safe. How can I do it? Maybe I should use C++ and link it from code in Java?
Click to expand...
Click to collapse
Put your secret code to server and call for calculations.
You can also use different sort of "black boxes" (if your apk running on some custom hardware).
Finally, you can try to use native code with heavy obfuscation, but I do not know reliable tools for android (arm) like VMProtect for x86/x64 code.
There is no 100% protection if you're shipping your algorithm with APK.
I would think of solving the problem from legal standpoint - file a patent. If your algorithm worthwhile you'll get the patent, otherwise there is no valid reason to put huge effort to protect it.
Thanks for all the answers. So there is no possible solution to protect algorithm at least as much as it is "hidden" in compiled C++ code?
I always write the secret code in JNI. (such as DRM) The java code always can be decompiler.
The best ways are:
1. Move algorithm to your server, execute on it, and send result to Android client.
But, this method has disadvantages:
- Your app will not work in offline mode.
- You will have extra load on your server. If you have many app users, you can have heavy server load.
2. Move algorithm code to C/C++ using Android NDK.
3. Generate algorithm at runtime. Split algorithm to many parts and insert dull parts (they do something, but don't affect algorithm - they are just for obfuscation purposes).
Something like this:
Code:
// algorithm part
interface Part {
double process(double arg0, double arg1);
}
class DullPart1 implements Part {
public double process(double arg0, double arg1) {
double i = 0;
i++;
i += arg1;
// and more dull actions here
}
}
Then make code that will call each part in predefined sequence and insert dull parts to it.

C++: open file for writing in the LocalStorage

Hi guys, could you tell me how to open file for writing in the phone app LocalStorage for the non-unlocked handset (regular app for store)?
Code below doesn't work
Code:
FILE *tmp;
auto tmpPath = Windows::Storage::ApplicationData::Current->LocalFolder->Path + "\\tmp.txt";
auto tmpErr = _wfopen_s(&tmp, tmpPath->Data(), L"w");
Any suggestions?
Try looking though msdn articles. I found it somewhere in there. But I have forgotten it now.
Sent from Board Express on my Nokia Lumia 1020. Best phone ever!!
Note to noobs: DON'T PM ME WITH QUESTIONS. POST IN THE FORUMS. THAT'S WHAT THEY ARE HERE FOR!
@wcomhelp, please keep your rtfm advices for yourself, OK? I'm not a noob and of course I've searched msdn, google, codeplex, github etc. and so on before posting here. If you don't know how, much better be silent (like others who read this post but have no idea what I'm talking about)
I've tried a few possible methods including ugly "MS-way" with task & lambda syntax (see below) but nothing worked as it should be (code below works if no file exist and fails if file already exist - CreationCollisionOption::ReplaceExisting options is not worked/not implemented/buggy/billgates_knows_only ).
Code:
auto folder = Windows::Storage::ApplicationData::Current->LocalFolder;
Concurrency::task<Windows::Storage::StorageFile^> createFileOp(
folder->CreateFileAsync(CONFIG_FILE_NAME, Windows::Storage::CreationCollisionOption::ReplaceExisting));
createFileOp.then([=](Windows::Storage::StorageFile^ file)
{
return file->OpenAsync(Windows::Storage::FileAccessMode::ReadWrite);
})
.then([=](Windows::Storage::Streams::IRandomAccessStream^ stream)
{
auto outputStream = stream->GetOutputStreamAt(0);
auto dataWriter = ref new Windows::Storage::Streams::DataWriter(outputStream);
// data save code skipped
return dataWriter->StoreAsync();
})
.wait();
BTW, I've used workaround, to save ported C++ app data to the LocalSettings instead of text file (as it was in original code).
"Doesn't work" doesn't give us a lot to go on, troubleshooting-wise. Can you tell us what error you get?
Only thing I see in the code that looks a little weird is that the
Code:
"\\tmp.txt"
part isn't explicitly a wide-character string, but I'd expect string concatenation to take care of that.
Also, out of curiosity, why libc functions instead of Win32? Obviously, the code you're writing here isn't intended for much portability...
@GoodDayToDie, there is no error code at all - standard POSIX functions returns NULL FILE, the ::GetLastError() also return 0.
I'm porting old C-style app to WinRT platform and don't care about portability (but the first post code - just a simplified example, nothing more).
POSIX (libc) functions works pretty well for reading only but not for writing - that's the problem...
As I said before, I resolved my issue by workaround but still curious why the POSIX calls fails for file writing in the app storage.
buuuuuuuuuuuuuuuuh
No need for lambdas
https://paoloseverini.wordpress.com/2014/04/22/async-await-in-c/
You may also want to rethink your strategy
You can't create files at arbitrary locations, so your method is kinda redundant. All the locations you are allowed to create and read files to/from are available through KnowFolders and ApplicationData classes. These return StorageFolders which in turn can create files with CreateFileAsync (used for both creating and opening existing files) and get files with GetFilesAsync ( I recommend against this one though) and similar methods.
@mcosmin222, could you please re-read my posts one more time? I'm not trying to create files at "arbitrary locations"; I wanna create/write simple text file at the app's local storage (which one should be available for reading/writing). And the problem not in the lambdas or task usage (yes, it looks ugly but it works as it supposed to be).
Could you provide a working example instead of words? And I'll be glad to say you "thanks a lot"; can't say now...
sensboston said:
@mcosmin222, could you please re-read my posts one more time? I'm not trying to create files at "arbitrary locations"; I wanna create/write simple text file at the app's local storage (which one should be available for reading/writing). And the main problem not in the task (async execution).
Could you provide a working example instead of words? And I'll be glad to say you "thanks a lot"; can't say now...
Click to expand...
Click to collapse
Sure, just gimmie a few hours till I can get near a compiler that is capable of doing that
Of course, no rush at all, take your time. It's not a showstopper for me now (actually, my workaround with AppSettings is more preferable way - at least for universal app and roaming settings) but the issue still has an "academic interest" and maybe will be useful in the next projects for porting old C/C++ code to WinRT.
sensboston said:
Of course, no rush at all, take your time. It's not a showstopper for me now (actually, my workaround with AppSettings is more preferable way - at least for universal app and roaming settings) but the issue still has an "academic interest" and maybe will be useful in the next projects for porting old C/C++ code to WinRT.
Click to expand...
Click to collapse
hi
in vs 2015
#include <pplawait.h>
Something of the like should work
Code:
WriteSomeFile() __resumable
{
auto local = ApplicationData::Current->LocalFolder;
auto file = __await local->CreateFileAsync("some file", CreationCollisionOption::eek:penIfExists);
__await FileIO::WriteTextAsync(file, "this is some text");
}
However, as of right now, in VS 2015 RC, you have a host of limitations when dealing with this, but I do not believe this will be of any issue to you.
Code:
Cannot use Windows Runtime (WinRT) types in the signature of resumable function and resumable function cannot be a member function in a WinRT class. (This is fixed, but didn't make it in time for RC release)
We may give a wrong diagnostic if return statement appears in resumable function prior to seeing an await expression or yield statement. (Workaround: restructure your code so that the first return happens after yield or await)
Compiling code with resumable functions may result in compilation errors or bad codegen if compiled with /ZI flag (Edit and Continue debugging)
Parameters of a resumable function may not be visible while debugging
Please see this link for additional details
http://blogs.msdn.com/b/vcblog/archive/2015/04/29/more-about-resumable-functions-in-c.aspx
you should also note that this works with native, standard C++ types.
@mcosmin222, looks like unbuffered writing works (i.e. without streams) fine but it still not an answer for my initial question
I'm curious why the standard POSIX libc writing operations are not working on the app's local storage (but reading from files works fine). Actually, it's all about porting old C/C++ code for WinRT; of course for the new app it's not a problem but re-writing old code to FileIO should be a huge pain in the ass. What I did: I've "mechanically" changed all libc formatted outputs from file to string, and use LocalSettings class (actually it's XML file) to store that string (I'm planning also change LocalSettings to RoamingSettings, to provide settings consistency between WP & desktop app).
P.S. <pplawait.h> is not available in my VS 2015 (release pro version) so I've tested by using lambda pattern.
OK, first things first, LIBC != POSIX! The POSIX way to do this would be to call the open() function and get back an int as an "fd" (file descriptor), which is of course not implemented on Windows Phone because Windows Phone is not a POSIX platform (you might find the Windows compatibility functions _open() and _wopen(), but I doubt it). You are attempting to use the standard C library functions, which are portable but implement kind of a lowest common denominator of functionality and are generally slightly slower than native APIs because they go through a portability wrapper.
Second, sorry to be all RTFM on you but you should really Read The Manual (or manpage, or, since this is Windows, the MSDN page)! Libc APIs set errno (include errno.h) and use different error values than Windows system error codes (or HRESULT codes, or NTSTATUS codes, or...). Error reporting in C is a mess. If you were calling CreateFile(), you would check GetLastError(), but since you're calling _wfopen(), you check errno (not a function).
@GoodDayToDie, _wfopen_s returns 0 (i.e. "no error") but tmp pointer receives also 0 (NULL) Could you explain why libc file functions are working for reading (at the app installation & local data folders of course) but not for writing? Any logical ("msdn based") explanation? Or you just... don't know, heh?
sensboston said:
@GoodDayToDie, _wfopen_s returns 0 (i.e. "no error") but tmp pointer receives also 0 (NULL) Could you explain why libc file functions are working for reading (at the app installation & local data folders of course) but not for writing? Any logical ("msdn based") explanation? Or you just... don't know, heh?
Click to expand...
Click to collapse
LIBC functions will most likely work just in debug mode. The moment you try to publish the app it will fail. You can do lots of crazy stuff on your developer device with basic C functions, but if you try publishing, it won't pass the marketplace verification.
Most C APIs are simply not supported, since they do not comply with the sandbox environment of the Windows Runtime.
The code I gave you is tested with VS 2015 RC. You should be able to include <pplawait.h> just fine, if you are targeting toolchains newer than November 2013.
mcosmin222 said:
The moment you try to publish the app it will fail. You can do lots of crazy stuff on your developer device with basic C functions, but if you try publishing, it won't pass the marketplace verification.
Click to expand...
Click to collapse
Hmm... Are you sure or it's just your assumption? My app is still under development but (just for test!) I've made store app package for WP and it passed local store verification I also uploaded package to the store (via browser) and it also passed. I don't have time to create all tiles and fill all fields to complete beta-submission (actually, I don't know how to mark app as beta in the new dashboard) but for me it looks like app don't have any problem and will pass store certification easily. And you may be sure - it uses A LOT of libc calls 'cause originally it was written for Linux (or kind of UX system)
sensboston said:
Hmm... Are you sure or it's just your assumption? My app is still under development but (just for test!) I've made store app package for WP and it passed local store verification I also uploaded package to the store (via browser) and it also passed. I don't have time to create all tiles and fill all fields to complete beta-submission (actually, I don't know how to mark app as beta in the new dashboard) but for me it looks like app don't have any problem and will pass store certification easily. And you may be sure - it uses A LOT of libc calls 'cause originally it was written for Linux (or kind of UX system)
Click to expand...
Click to collapse
Once usage reports get up to microsoft, you will be given a notice to fix the offending API (happened to be once). You are much better off using the platform specific tools: not only they are much faster, they are also much safer and you won't have problems later on.
You might get away with reading stuff (since reading is not that harmful), but you should be using the winRT APIs each time they are available.
Simply uploading your app to the marketplace just reruns the local tests in their cloud servers: once you submit the actual app (not beta, not tests) for consumers, it will be much more aggressively checked. This is because the store allows specific scenarios for distributing apps in close circles that may break the usual validation rules.
@mcosmin222, one more time: is it your assumptions or personal experience? I don't know how many apps you have in store (I do have a lot) but I never heard that you said. I've used C++ libraries with WP hacks in some of published apps but never had any problem with "aggressive checks". What I know: if you are using some "prohibited" calls, your app will not pass uploading to the store (uploading, not a certification).
P.S. I'll send you personally a link when I publish release Hope, you'll like it
sensboston said:
@mcosmin222, one more time: is it your assumptions or personal experience? I don't know how many apps you have in store (I do have a lot) but I never heard that you said. I've used C++ libraries with WP hacks in some of published apps but never had any problem with "aggressive checks". What I know: if you are using some "prohibited" calls, your app will not pass uploading to the store (uploading, not a certification).
P.S. I'll send you personally a link when I publish release Hope, you'll like it
Click to expand...
Click to collapse
By "hacking" you mean recompiling the code to fit the windows phone toolchain? if so, then you shouldn't have to worry about too many things.
but even so, calling stuff like fopen in locations other than local storage will get your app banned. Even if it makes past the first publication, you can get noticed weeks later or even months (yes, it did happen to me personally).
In most cases, calling C APIs that can potentially break the sandbox (like opening a file in doc library with fopen) will always fail the marketplace verification, eventually. If it hasn't happened to you yet, then you may have not been using such APIs.
No, my C++ code is not accessing other than approved locations but the app has a lot of libс (and of course other C/C++ libs) calls; I'm 99.9% sure it's legitimate and will be not a source of any problem. Otherwise what is the advantages of having C++ compiler?!
As far as I know, just some of API's are prohibited but you will notice it right after local store compatibility test run...
As for "hacks" I mean usage of undocumented ShellChromeAPI calls (including loading hack).
P.S. I've found why <pplawait.h> header is missing. Initially I've created solution with the 12.0 toolset but now I can't (or don't know how to) change it to 14. However creating the new empty universal solution in VS 2015 also gives me toolset 12 by default. What is the toolset 14 for? Windows 10?
sensboston said:
No, my C++ code is not accessing other than approved locations but the app has a lot of libс (and of course other C/C++ libs) calls; I'm 99.9% sure it's legitimate and will be not a source of any problem. Otherwise what is the advantages of having C++ compiler?!
As far as I know, just some of API's are prohibited but you will notice it right after local store compatibility test run...
As for "hacks" I mean usage of undocumented ShellChromeAPI calls (including loading hack).
P.S. I've found why <pplawait.h> header is missing. Initially I've created solution with the 12.0 toolset but now I can't (or don't know how to) change it to 14. However creating the new empty universal solution in VS 2015 also gives me toolset 12 by default. What is the toolset 14 for? Windows 10?
Click to expand...
Click to collapse
The advantage of C++ is the obvious versatility: the standard C++ APIs will work fine for you as long as you stay inside the sandbox (this means you can't access files even in locations that are outside of sandbox but you have permission to them, such as music library). You can use most classic C/C++ libraries without issues as long as you do the interface with the runtime broker yourself. That means using windows runtime APIs instead of classic C APIs when dealing with stuff such as file access, for example. This is a pretty extensive topic and It is rather difficult to explain it all with 100% accuracy, especially when there is lots of docs running around.
You also get deterministic memory management, which is huge in specific scenarios.
Long story short
You will be fine with standard C/C++ when using
any in-memory functions supported by the compiler (you can manipulate data types, string, mutex, etc).
File IO in isolated storage only (applicationData folder)
Threads (although you are better off using threadpool or the like, it is much easier and cleaner). You can also use futures, and std::this_thread.
You will have to use winRT replacement
File system access in any other location than application data (you must use the windows::storage APIs)
sockets, internet access and the like.
any hardware related thing: music&video playerback must be interfaced through winRT (although the underlying decoders can be classic C/C++), messing around with the device sensors.
Retrieving system properties (internet connection state etc)
cross process communications
communicating with other apps
There are also win32 equivalents
mutex, threading, fileIO (isolated storage only)
Media playback with custom rendering pipeline.
Basically, winRT functions as an abstraction layer between the hardware and your code. You can use classic C++ up to the point where you need to interact with the system in any way. At that point, system interaction must be done with winRT. This way, microsoft ensures a higher degree of stability and security for devices.
check this link out for more information on the toolchains. You should be able to use this in VS 2013 as well with windows 8 (this is a compiler feature, has nothing to do with supported platform)
https://paoloseverini.wordpress.com/2014/04/22/async-await-in-c/

Categories

Resources