ELIF BONCUK: Hi, my name's Elif.
I work as a software specialist at Garanti Technology Mobile
Applications team.
iGaranti and Cep [? Subesi, ?] which
are our most popular banking applications,
are our team's products.
There are lots of different devices in the market with lots
of different capabilities.
Because of being a bank, we should provide service
to all of our customers.
And some of the devices have some low memory issues.
"Don't keep activities" options, which is lying under developer
options, gives us the opportunity of assimilating
these low memory issues.
Today I'm going to tell you the most important and common
low memory issue, which is your activities being created.
The system may destroy your activity
if it's stopped, or hasn't been used for a long time,
or the foreground's activity needs more resources.
So, the system will destroy your activity to recover the memory.
Let's think about money transfer transaction.
There are lots of selections in the page-- [INAUDIBLE] account,
branch selection.
If a low memory issue happens on the user selection page--
let's say account selection-- the user selects the account
and turns back to the main page.
And because of low memory, all the selections,
all the fields will be cleared.
If your activity stops because of a low memory issue,
then a save instance statement will be called by the system.
And you can save all your data-- what you want-- in this method.
And after recreating your activity,
the Restore Instant Statement [INAUDIBLE] will be called.
So, you can restore back all your data in here,
and the system uses [? model ?] [? objects ?] in this solution.
The official solution wasn't enough in our case,
because being we created [INAUDIBLE] activity
means to us, the users start transaction from main start
and select all the selections again and again.
And of course, we could use on-service statement
[INAUDIBLE] and official solution.
But it would miss high cost [INAUDIBLE]
assimilated to problem and develop another solution.
If you use one activity for a whole transaction
and a fragment for each related page,
then your activity won't be recreated,
and you will complete your transaction in one activity.
If you want to solve the foreground/background canvas,
you can use custom components, on-service [INAUDIBLE],
activities on-service [INAUDIBLE].
And you can save all the data.
But if you think about your users--
users in other application or at another transaction--
it's not a very good problem to lose the data which
is not using one.
One last issue I want to talk about
is our bundle object, which you use for saving data and passing
data between activities.
Bundle object has a maximum storage limit.
And if you have to keep more than this maximum limit,
then you have to develop some other solutions.
In that case, you want to use your device's local storage,
maybe.
But it won't be a safe solution.
Our solution is, in that case, use
a hash map that will allow [INAUDIBLE] our application.
I'll talk about the common low memory issue
and how we solve it.
My advice to all Android developers--
select this option before submission
and control their applications.
They don't have to solve every low memory issue.
But at least they could known which problems the users
are faced with.
[MUSIC PLAYING]