Will it auto release when the user quit the application? or it will stay in the machine until reboot? Also, have Apple provides any tools for developer to check whether they release the object or not.
Probably everything related to the app will be destroyed when the app terminates. The memory leak affect the memory usage of your application. It uses up memory, it's bad practice and it may introduce bugs.
About the tool, if you are using xcode then check out the very cool integrated Static Analyzer on the same page.
Related
I am new to react-native and implementing simple app where app will monitor the mobile's clock time and should set some flags so as to notify user to perform some task when he starts the app.
I want to continuously monitor mobile's clock time as a background job in the react native app such that, when user opens the app and if specific time has already passed, it should set some flag to take future decision.
After some research over blogs, I found that react-native-background-task and/or background-timers can be used. But I am finding difficulty in implementing it. Can anyone help me with the implementation example for the same.
Thank you in advance.
So, from your post I'm going to assume a few things. One being you'll develop on Android as well as iOS, you just want to use a plugin (not code a module yourself).
Unfortunately, unless I'm mistaken - there's no simple answer and I'll explain.
As Android and iOS go forward they are starting to limit usage of Apps in the background, specifically Android goes into 'Doze' mode and iOS works in a similar fashion.
For Android, you'll need to consider a few things and I'll concentrate on them, as you'll need to know this before actually creating a RN app.
Doze Mode
Starting from Android 6.0 (API level 23), Android introduces two
power-saving features that extend battery life for users by managing
how apps behave when a device is not connected to a power source. Doze
reduces battery consumption by deferring background CPU and network
activity for apps when the device is unused for long periods of time.
App Standby defers background network activity for apps with which the
user has not recently interacted.
While the device is in Doze, apps' access to certain battery-intensive
resources is deferred until maintenance windows. The specific
restrictions are listed in Power Management Restrictions.
Doze and App Standby manage the behavior of all apps running on
Android 6.0 or higher, regardless whether they are specifically
targeting API level 23. To ensure the best experience for users, test
your app in Doze and App Standby modes and make any necessary
adjustments to your code. The sections below provide details.
Cruically, you'll need to note:
The system does not allow sync adapters to run.
The system does not allow JobScheduler to run.
So firstly for android, you'll (probably) need to ensure your app is in a 'whitelist'. You can check the requirements of the list here:
https://developer.android.com/training/monitoring-device-state/doze-standby
Or, you can access the maintenance window with a plugin like here:
https://github.com/transistorsoft/react-native-background-fetch
Testing
Android give you some tools to do so, mainly running:
$ adb shell dumpsys battery unplug
$ adb shell am set-inactive <packageName> true
Headless JS
You can check out headless tasks, which could suit your situation:
https://facebook.github.io/react-native/docs/headless-js-android
Caveats:
Although Android state that the operating system itself acts like documented, devices themselves can have software built in which essentially kills background processes. Nokia is one of the worst. So be aware of this.
I was trying to program a simple TODO app for Yosemite with sandboxing. Apple has its tutorials for the same but they are not very elaborate. I wanted to know sandbox APIs like sandbox_init() and APIs for console logs (heard sandboxed apps use some special APIs). Could someone please point me to some open source app with sandboxing on Yosemite, so that I could see the APIs that it is using.
You don't need to use sandbox_init() etc. in order to create a sandboxed app.
Roughly, you need to understand:
Use the APIs to find well known directories and don't assume that /Users/username/Documents is the Documents folder, for example.
The app has no access to user files and must gain access via NSOpenPanel.
If the app wants to retain access it has already gained then it needs to create and store bookmark URLs, which can be reloaded during a later invocation.
If the sandboxed app spawns a child process, then that child process needs it's own set of entitlements.
Once you understand that it's normally just a case of setting Use Sandbox in the app capabilities and you're off.
We are developing a new Windows Store App with C# now. It is strange that the app crashed occasionally but haven't given any infomation . Now we deploy an IDE on the Surface and use it to run our code. The app crashed as the same, and the IDE didn't give any information.
So we want to know if Win8 system will kill app at some special cases ?
By the way, our all code blocks had using try-catch and we use async and await very carefully.
Most crash happend when the App access some network service.
Thank you very much!
every body!
I think there is not any systematic mechanism to make our app crash. But some bugs on the system really influence the quality of the software.
As our app, it crashed many times when using grouped GridView and when the pages enabled NavigationCachemode. After removing these features, it crashed less.
I read about Worklight's Direct Update feature already. However, I still have some questions that would like to clarify:
Q1: Is it true that Apple allows Worklight Apps to be published to APP
Store even there is a direct update feature?
Q2: How will Apple review and monitor the Worklight Apps' content if
there is a huge change after the direct update? Or, Apple does not
worry about the cached web resource in the application, does it?
Q3: Is there any limitation or pre-condition about the direct update
for the web resource? For example, the major entries of html and js
script files must be existed... etc.
Q1: Is it true that Apple allows Worklight Apps to be published to APP Store even there is a direct update feature?
A1: There are existing Worklight customers that have submitted an application to the App Store and passed Apple's app submission process. For best results, make sure you use Worklight v5.0.6.1 or later.
Q2: How will Apple review and monitor the Worklight Apps' content if there is a huge change after the direct update? Or, Apple does not worry about the cached web resource in the application, does it?
A2: Apple only reviews app submissions to the App Store and whether or not they follow their guidelines. They do not review future updates to the application (as long as it was not re-submitted), for example in the form of a Direct Update unless there are some extra-ordinary circumstances (like inappropriate content that was discovered afterwards, for example...)
Q3: Is there any limitation or pre-condition about the direct update for the web resource? For example, the major entries of html and js script files must be existed... etc.
A3: I am not entirely sure I understand the question. There is no limitation in Direct Update - this feature replaces the existing web resources of an application with new ones. The only thing I can think of is that both the Worklight Studio (that the app was created on) and Worklight Server (that the app lives on) must be of the same version number.
An update.
Apple now allows code updates if you use a webview
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts,
code and interpreters are packaged in the Application and not
downloaded. The only exception to the foregoing is scripts and code
downloaded and run by Apple's built- in WebKit framework, provided
that such scripts and code do not change the primary purpose of the
Application by providing features or functionality that are
inconsistent with the intended and advertised purpose of the
Application as submitted to the App Store.
We have developed a Groovy application. Under development for starting it we use the following command line
C:\myapp>mvn grails:run-app
Without sending any request to the server one can see how the memory used by the java process in increasing and increasing. When it starts at about 100M are allocated and a couple of hours later -without doind anything- the memory goes up to 300M.
When I start the application directly
C:\myapp> grails run-app
the memory consume is somehow different, without sending any request it is somehow stabilized at 110M. Sometimes goes up, sometimes comes down.
Although 300M is not critical I would like to know if this is a memory leak or not.
Is anybody having similar behaviours?
Thanks!
This could be a memory leak in Maven, but more likely a leak in the grails:run-app command. I would suggest posting this on the Grails development mailing list.
Why does this concern you? You should only be using these commands for development, not production as you'd be deploying a war file in production. If you're simply concerned, the Grails development mailing list is definitely the place for something like this.
I doubt there's a memory leak here.
It's perfectly normal for the JVM to wait on doing a full GC until it has to. That means if you allocate more memory, your java/groovy process will happily consume it.
Most likely you have different default memory settings for Maven vs Grails. I'm not sure exactly how these properties are set in windows, but they look something like:
GRAILS_OPTS="-Xms100m -Xmx110m"
MAVEN_OPTS="-Xms100m -Xmx300m"