Theory
તમે ક્યાં છો એ જાણવા માગતી app
FestConnect Mobile પાસે એક સરસ સુવિધાનો વિચાર છે: user ની સૌથી નજીકનાં fest નાં સ્થળો બતાવવાં. એ માટે ફોનનું સ્થાન જોઈએ.
પણ સ્થાન ઊંડે સુધી અંગત બાબત છે, એટલે Android એ એમ જ સોંપી દેતું નથી. App એ જાહેર કરવું પડે કે એને સ્થાન જોઈએ છે, ચાલુ કામ દરમિયાન user ને પૂછવું પડે, એની સ્પષ્ટ સંમતિ મેળવવી પડે, અને 'ના' પણ સહજતાથી સ્વીકારવી પડે. આ પાઠ user નું વર્તમાન સ્થાન સાચી અને ખાનગીપણાને માન આપતી રીતે મેળવવાનું શીખવે છે. ટેક્નિકલ ભાગ ટૂંકો છે; ખરો પાઠ તો permission વાળો ભાગ છે, અને એ BCA402-02 માં જોયેલા UX અને વિશ્વાસના સિદ્ધાંતોનો પડઘો પાડે છે.
Theory
Permissions: પહેલાં જાહેર કરો, પછી ચાલુ કામ દરમિયાન માગો
સ્થાન એ જોખમી (સંવેદનશીલ) permission છે, એટલે એને વાપરવા માટે બે પગથિયાં લેવાં પડે:
- એને manifest માં જાહેર કરો:
ACCESS_FINE_LOCATION(ચોક્કસ, GPS) અથવાACCESS_COARSE_LOCATION(અંદાજિત, network પર આધારિત) - એને ચાલુ કામ દરમિયાન માગો (Android 6.0 થી ફરજિયાત): user ને એવો permission નો સંવાદ બતાવો જેમાં એ મંજૂરી આપી કે નકારી શકે
સ્થાન વાપરતાં પહેલાં તમારે તપાસવું પડે કે permission મળી છે કે નહીં (ContextCompat.checkSelfPermission), અને ન મળી હોય તો માગવી પડે, અને નકાર પણ સહજતાથી સંભાળવો પડે (એ સુવિધા ફક્ત નહીં ચાલે, અને app એ ભાંગી પડ્યા વગર સરસ રીતે ઓછું કામ કરવું જોઈએ). આધુનિક Android પર ફક્ત જાહેર કરવું પૂરતું નથી; સંવેદનશીલ permissions માટે user ની ચાલુ કામ દરમિયાનની સંમતિ ફરજિયાત છે.
Practical
Permission તપાસો કે માગો, પછી સ્થાન મેળવો
// 1. Manifest માં ACCESS_FINE_LOCATION જાહેર કરેલું છે
// 2. ચાલુ કામ દરમિયાન તપાસો; મળી ન હોય તો માગો
fun ensureLocationPermission() {
if (ContextCompat.checkSelfPermission(this,
Manifest.permission.ACCESS_FINE_LOCATION)
!= PackageManager.PERMISSION_GRANTED) {
// મળી નથી: user ને પૂછો
requestPermissions(
arrayOf(Manifest.permission.ACCESS_FINE_LOCATION), 100)
} else {
getLocation() // પહેલેથી મળી ગઈ છે
}
}
// 3. સ્થાન મેળવો (asynchronous, Google Play Services દ્વારા)
fun getLocation() {
val client = LocationServices.getFusedLocationProviderClient(this)
client.lastLocation.addOnSuccessListener { loc ->
if (loc != null) {
val lat = loc.latitude
val lng = loc.longitude // નજીકનાં સ્થળો બતાવવા lat/lng વાપરો
}
}
}
Theory
સ્થાન મેળવવું, અને coarse સામે fine
સ્થાન વાંચવાની આધુનિક રીત એટલે FusedLocationProviderClient (Google Play Services માંથી), જે GPS, wifi અને network ના સંકેતોને સમજદારીથી ભેગા કરે છે. client.lastLocation છેલ્લે જાણેલું Location (જેમાં latitude અને longitude હોય) callback દ્વારા આપે છે, અને એ પણ asynchronous રીતે, એટલે કે પરિણામ પછીથી આવે છે, તરત નહીં.
ચોકસાઈનાં બે સ્તર છે:
- coarse (ACCESS_COARSE_LOCATION): અંદાજિત, network પર આધારિત, ઓછી battery વાપરે, અને 'કયું શહેર કે વિસ્તાર' જાણવા માટે પૂરતું
- fine (ACCESS_FINE_LOCATION): ચોક્કસ, GPS વાળું, વધુ battery વાપરે, અને બરાબર સ્થાન નક્કી કરવા માટે
જેટલી ચોકસાઈ ખરેખર જોઈએ એટલી જ માગો: જો FestConnect ને ફક્ત નજીકના શહેરનાં સ્થળો જ બતાવવાં હોય, તો coarse પૂરતું છે, અને એ fine GPS માગવા કરતાં user ની battery તથા ખાનગીપણાને વધુ માન આપે છે.
Quiz
User નું વર્તમાન સ્થાન વાપરી શકે એ પહેલાં Android app એ શું કરવું પડે?
- કંઈ નહીં; સ્થાન બધી apps ને મુક્તપણે મળી જ જાય છે
- Manifest માં location permission જાહેર કરવી અને ચાલુ કામ દરમિયાન એ માગવી, user એ મંજૂરી આપી છે એ તપાસવું (અને નકાર પણ સંભાળવો)
- ફક્ત manifest માં જાહેર કરવી; એટલું પૂરતું છે
- App install થાય ત્યારે એક જ વાર પૂછવું
Show the answer
Manifest માં location permission જાહેર કરવી અને ચાલુ કામ દરમિયાન એ માગવી, user એ મંજૂરી આપી છે એ તપાસવું (અને નકાર પણ સંભાળવો)
સ્થાન એ સંવેદનશીલ (જોખમી) permission છે, એટલે app એ manifest માં એને જાહેર પણ કરવી પડે અને ચાલુ કામ દરમિયાન એ માગવી પણ પડે (Android 6.0 થી), તથા સ્થાન વાપરતાં પહેલાં user એ મંજૂરી આપી છે કે નહીં એ તપાસવું પડે અને નકાર સહજતાથી સંભાળવો પડે. વિકલ્પ A ખોટો છે અને એવું હોય તો ખાનગીપણાનો ગંભીર ભંગ થાય, કારણ કે સંવેદનશીલ data કદી મુક્તપણે મળતો નથી. વિકલ્પ C એ Android 6.0 પહેલાંનો ઢાંચો છે: હવે ફક્ત જાહેર કરવું પૂરતું નથી; જોખમી permissions માટે ચાલુ કામ દરમિયાનની સંમતિ જરૂરી છે. વિકલ્પ D install વખતની જૂની રીતનું વર્ણન કરે છે, જેને આધુનિક Android એ ચાલુ કામ દરમિયાનની વિનંતીઓથી બદલી નાખી છે (જેથી users સંદર્ભ સાથે નક્કી કરી શકે અને પછીથી પાછી પણ ખેંચી શકે). નિયમ આ રહ્યો: જાહેર કરો, ચાલુ કામ દરમિયાન માગો, મંજૂરી મળી છે એ તપાસો અને 'ના' સંભાળો, કારણ કે પોતાના સ્થાન જેવો સંવેદનશીલ data વહેંચવા માટે user ની સંમતિ જરૂરી છે.
Think first
વિશ્વાસ માટે runtime permissions કેમ મહત્ત્વની છે
જૂનું Android install વખતે જ બધી જાહેર કરેલી permissions આપી દેતું; આધુનિક Android ચાલુ કામ દરમિયાન, સંદર્ભ સાથે પૂછે છે. BCA402-02 ના UX સિદ્ધાંતો સાથે જોડીને કહો, users માટે આ રીત વધુ સારી કેમ છે? વિચારીને પછી tap કરો.
Show the answer
ચાલુ કામ દરમિયાનની રીત users ને અર્થપૂર્ણ કાબૂ આપે છે અને વિશ્વાસ ઊભો કરે છે. Install વખતે permissions એ text ની એવી દીવાલ હતી જે કોઈ વાંચતું નહોતું અને જેમાં બધું કે કંઈ નહીં જેવો વિકલ્પ હતો, અને app વાપરવી હોય તો બધું આપવું જ પડતું, એટલે સંમતિ પોકળ હતી. ચાલુ કામ દરમિયાનની વિનંતીઓ સંવેદનશીલ permission ત્યારે માગે છે જ્યારે એ ખરેખર જોઈએ, અને તે પણ સંદર્ભ સાથે ('FestConnect ને નજીકનાં સ્થળો બતાવવા તમારું સ્થાન જોઈએ છે'), એટલે user સમજે છે કે શા માટે અને સમજપૂર્વકની પસંદગી કરી શકે છે, એટલે કે મંજૂરી આપવી, નકારવી, કે એક જ વાર માટે આપવી. એ પછીથી settings માં જઈને એ પાછી પણ ખેંચી શકે છે. આ user ની સ્વાયત્તતા અને ખાનગીપણાને માન આપે છે, અને સારી રીતે વર્તતી app સમજાવે છે કે એને permission શા માટે જોઈએ છે અને નકાર મળે તો સહજતાથી ઓછું કામ કરે છે (નજીકનાં સ્થળોની સુવિધા ફક્ત દેખાતી નથી), નહીં કે વારંવાર કચકચ કરે કે ભાંગી પડે. BCA402-02 નો UX અને વિશ્વાસનો સિદ્ધાંત બરાબર આ જ છે: user ને માન આપો, પારદર્શક રહો, અને જરૂર કરતાં વધારે ક્યારેય ન માગો. Runtime permissions સંમતિને ઔપચારિકતામાંથી ખરી, સંદર્ભવાળી પસંદગીમાં ફેરવે છે, જે નૈતિક રીતે પણ સારું છે અને UX ની દૃષ્ટિએ પણ.
Watch out
સ્થાનના ફાંદા
જાહેર કરવું પણ ચાલુ કામ દરમિયાન ન માગવું: આધુનિક Android પર સંવેદનશીલ permissions ચાલુ કામ દરમિયાન માગવી જ પડે, ફક્ત જાહેર કરવાથી ચાલતું નથી.
નકાર ન સંભાળવો: user ના પાડે તો સુવિધાએ સહજતાથી ઓછું કામ કરવું જોઈએ, ભાંગી પડવું નહીં.
સ્થાન તરત મળી જશે એમ માનવું: એ callback દ્વારા asynchronous રીતે આવે છે; પરિણામ ત્યાં જ સંભાળો, અને null વાળો કિસ્સો પણ.
Coarse પૂરતું હોય ત્યાં fine માગવું: જેટલી ચોકસાઈ જોઈએ એટલી જ માગો (battery, ખાનગીપણું, વિશ્વાસ).
કારણ ન સમજાવવું: user ને સંદર્ભ સાથે કહો કે તમને સ્થાન શા માટે જોઈએ છે; એથી મંજૂરીનું પ્રમાણ અને વિશ્વાસ બંને વધે છે.
Theory
સ્થાન પૂરું; device ની એક શક્તિ બાકી
FestConnect Mobile હવે user ની સંમતિથી એનું સ્થાન શોધી શકે છે અને નજીકનાં સ્થળો બતાવી શકે છે. device ની છેલ્લી સુવિધા, અને આ unit નો છેલ્લો ટેક્નિકલ પાઠ, એટલે camera: camera app ને implicit intent મોકલીને device ના camera થી છબી લેવી. પછી Unit 4 IKS ની લીલાવતી વાળા ગણિત તરફ વળે છે. App ને એની છેલ્લી ક્ષમતા મળે છે, અને પછી વિષયનો ગણિતવાળો unit આવે છે.
Summary
Key takeaways
- સ્થાન સંવેદનશીલ (જોખમી) permission છે: app એ એને manifest માં જાહેર પણ કરવી પડે અને ચાલુ કામ દરમિયાન માગવી પણ પડે.
- ACCESS_FINE_LOCATION (ચોક્કસ, GPS) કે ACCESS_COARSE_LOCATION (અંદાજિત, network) જાહેર કરો; અને જેટલી ચોકસાઈ જોઈએ એટલી જ માગો.
- ચાલુ કામ દરમિયાન (Android 6.0 થી): ContextCompat.checkSelfPermission તપાસો, મળી ન હોય તો માગો, અને નકાર સહજતાથી સંભાળો.
- સ્થાન FusedLocationProviderClient (Google Play Services) વડે મેળવો; lastLocation asynchronous રીતે Location (latitude અને longitude) આપે છે.
- પરિણામ callback દ્વારા (asynchronous) આવે છે અને null પણ હોઈ શકે; બંને સંભાળો.
- સંદર્ભ સાથે ચાલુ કામ દરમિયાન માગેલી permissions user ના વિશ્વાસ અને કાબૂને માન આપે છે (BCA402-02 UX): કારણ સમજાવો, અને નકાર મળે તો સહજતાથી ઓછું કામ કરો.
- યાદ રાખવાની કડી: જાહેર કરો, ચાલુ કામ દરમિયાન માગો, મંજૂરી તપાસો અને 'ના' સંભાળો; સ્થાન આપવું કે નહીં એ user ના હાથમાં છે.