പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

പൊതുവായ അനുമതികളും ക്രാഷുകളും

ഞങ്ങൾ അനുമതികളൊന്നും ചേർത്തില്ലെങ്കിൽ എന്ത് സംഭവിക്കും? അത് തകരുമോ?

ഇല്ല, ട്രെയ്‌സ്‌ലെറ്റ് തകരാറിലാകില്ല. ട്രെയ്‌സ്‌ലെറ്റ് രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നത് ഉയർന്ന പ്രതിരോധശേഷിയുള്ളതാണ്. നിർബന്ധിത ലൊക്കേഷൻ അനുമതികൾ പ്രഖ്യാപിക്കാതെയോ അഭ്യർത്ഥിക്കാതെയോ Tracelet.start() എന്ന് വിളിക്കാൻ നിങ്ങൾ ശ്രമിക്കുകയാണെങ്കിൽ, Tracelet മനോഹരമായി സെക്യൂരിറ്റി എക്‌സെപ്ഷൻ പിടിക്കുകയും കൺസോളിൽ ഒരു വിശദമായ പിശക് രേഖപ്പെടുത്തുകയും നിങ്ങളുടെ ശ്രോതാക്കൾക്ക് ഒരു പരാജയ സംഭവം നൽകുകയും ചെയ്യും. ആപ്പ് തന്നെ സാധാരണ രീതിയിൽ പ്രവർത്തിക്കുന്നത് തുടരും. എന്നിരുന്നാലും, അനുമതികൾ ലഭിക്കുന്നതുവരെ ലൊക്കേഷനുകളൊന്നും രേഖപ്പെടുത്തില്ല.

നമ്മൾ ചലന (ശാരീരിക പ്രവർത്തനം) അനുമതി പ്രവർത്തനക്ഷമമാക്കിയില്ലെങ്കിൽ എന്ത് സംഭവിക്കും?

ഇല്ല, അത് ക്രാഷ് ആകില്ല. ACTIVITY_RECOGNITION (Android) അല്ലെങ്കിൽ Motion & Fitness (iOS) അനുമതി നൽകിയില്ലെങ്കിൽ, Tracelet യാന്ത്രികമായി സ്റ്റാൻഡേർഡ് ഡിസ്റ്റൻസ് അധിഷ്ഠിത ട്രാക്കിംഗിലേക്ക് മടങ്ങും. എന്നിരുന്നാലും, ബാറ്ററി ഡ്രെയിൻ ഗണ്യമായി വർദ്ധിക്കും. ചലനം കണ്ടെത്താതെ, ഉപകരണം നിശ്ചലമായിരിക്കുമ്പോൾ ട്രാക്ക്‌ലെറ്റിന് GPS ഹാർഡ്‌വെയറിനെ നിദ്രയിലാക്കാൻ കഴിയില്ല. ഒപ്റ്റിമൽ ബാറ്ററി ലൈഫ് ഉറപ്പാക്കാൻ പ്രൊഡക്ഷൻ ആപ്പുകൾക്കായി ഈ അനുമതി അഭ്യർത്ഥിക്കാൻ വളരെ ശുപാർശ ചെയ്യുന്നു.

iOS ബിൽഡും സജ്ജീകരണവും

”നിർവചിക്കാത്ത ചിഹ്നം” റസ്റ്റ്/യൂണിഎഫ്എഫ്ഐ പിശകുകൾ ഉപയോഗിച്ച് iOS ബിൽഡ് പരാജയപ്പെടുന്നു (`_ffi_tracelet_core_rustbuffer_free`, `_uniffi_tracelet_core_checksum_method_*`)

Flutter’s Swift Package Manager ഇൻ്റഗ്രേഷൻ പ്രവർത്തനക്ഷമമാക്കുക. Tracelet’s Rust core (tracelet_ios ഉപയോഗിക്കുന്ന UniFFI ചിഹ്നങ്ങളെ തുറന്നുകാട്ടുന്ന TraceletCore.xcframework) Swift Package Manager വഴി ലിങ്ക് ചെയ്‌തിരിക്കുന്നു. ലെഗസി CocoaPods-only path-ൽ, ചട്ടക്കൂട് tracelet_ios ടാർഗെറ്റിലേക്ക് ലിങ്ക് ചെയ്തിട്ടില്ല, അതിനാൽ Xcode-ൻ്റെ ലിങ്കർ _ffi_tracelet_core_rustbuffer_free, _uniffi_tracelet_core_checksum_method_* എന്നിവ പോലുള്ള നിർവചിക്കാത്ത ചിഹ്നങ്ങൾ റിപ്പോർട്ട് ചെയ്യുന്നു.

ഇത് ഉപയോഗിച്ച് പരിഹരിക്കുക:


flutter config --enable-swift-package-manager
flutter clean
flutter pub get
flutter run        # or: flutter build ios

കുറിപ്പുകൾ:

.xcworkspace തുറന്ന് Xcode-ൽ നിന്ന് നേരിട്ട് നിർമ്മിക്കുന്നതിനുപകരം, SPM-അവബോധമുള്ള ബിൽഡിനെ നയിക്കുന്ന Flutter CLI അല്ലെങ്കിൽ നിങ്ങളുടെ IDE (VS കോഡ്)-ൽ നിന്ന് നിർമ്മിക്കുക/ പ്രവർത്തിപ്പിക്കുക.
ഇതൊരു ഒറ്റത്തവണ ആഗോള ഫ്ലട്ടർ ക്രമീകരണമാണ്; ഓരോ പ്രോജക്റ്റിനും നിങ്ങൾ ഇത് മാറ്റേണ്ടതില്ല.
flutter clean + ഒരു പുതിയ pod install മാത്രം അത് പരിഹരിക്കില്ല അല്ല - നഷ്ടമായത് റസ്റ്റ് ചട്ടക്കൂടിനെ ബന്ധിപ്പിക്കുന്ന SPM ആണ്, പഴകിയ പോഡുകളല്ല.

ബാറ്ററി & മോഷൻ സെൻസറുകൾ

നടക്കുമ്പോൾ മോഷൻ സെൻസർ കൂടുതൽ ബാറ്ററി കളയുമോ?

ഇല്ല, ഇത് യഥാർത്ഥത്തിൽ ബാറ്ററി ലാഭിക്കുന്നു. ഹാർഡ്‌വെയർ മോഷൻ സെൻസറുകൾ (ആക്‌സിലറോമീറ്റർ/സ്റ്റെപ്പ് ഡിറ്റക്ടർ) മണിക്കൂറിൽ 0.1% ബാറ്ററിയിൽ കുറവാണ് ഉപയോഗിക്കുന്നത്. ഫോൺ ഡെസ്‌കിൽ വിശ്രമിക്കുമ്പോഴെല്ലാം വളരെ പവർ-ഹംഗ്റി ജിപിഎസ് ചിപ്പ് (മണിക്കൂറിൽ 4-8% കളയുന്നു) പൂർണ്ണമായും ഓഫ് ചെയ്യാൻ Tracelet ഈ അൾട്രാ ലോ-പവർ സെൻസർ ഉപയോഗിക്കുന്നു.

നിങ്ങൾ നടക്കാൻ തുടങ്ങുമ്പോൾ, യാത്ര റെക്കോർഡുചെയ്യാൻ ചലന സെൻസർ ഉടൻ തന്നെ GPS ഉണർത്തുന്നു. പരമ്പരാഗത ട്രാക്കിംഗുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ മൊത്തത്തിലുള്ള ഫലം ബാറ്ററി ലൈഫിനുള്ള ഒരു വലിയ പോസിറ്റീവ് ആണ്.

ഫോൺ ചലിക്കാത്തപ്പോൾ എന്തുകൊണ്ടാണ് എനിക്ക് തുടർച്ചയായ അപ്‌ഡേറ്റുകൾ ലഭിക്കാത്തത്?

ഇത് മനഃപൂർവമാണ് - ഇത് നൽകുന്ന ഏറ്റവും വലിയ ബാറ്ററി ലാഭിക്കൽ ട്രെയ്‌സ്‌ലെറ്റാണ്. ഉപകരണം നിശ്ചലമാണെന്ന് മോഷൻ ഡിറ്റക്ഷൻ നിർണ്ണയിക്കുമ്പോൾ, ട്രേസ്‌ലെറ്റ് തുടർച്ചയായ ജിപിഎസ് പ്രവർത്തനരഹിതമാക്കുകയും ലോ-പവർ മോഡിലേക്ക് മാറുകയും ചെയ്യുന്നു (ആനുകാലിക ഒറ്റത്തവണ പരിഹാരങ്ങൾ അല്ലെങ്കിൽ ജിയോഫെൻസ് നിരീക്ഷണം). യഥാർത്ഥ ചലനം പുനരാരംഭിക്കുന്ന നിമിഷം, തുടർച്ചയായ ട്രാക്കിംഗ് യാന്ത്രികമായി ഉണരും.

നിശ്ചലാവസ്ഥയിൽ നിങ്ങൾക്ക് ഇപ്പോഴും “ഞാൻ ഇവിടെയുണ്ട്” എന്ന ആനുകാലിക ലൊക്കേഷൻ വേണമെങ്കിൽ, heartbeatInterval (സെക്കൻഡ്) സജ്ജമാക്കുക. പാർക്ക് ചെയ്‌തിരിക്കുമ്പോൾ ചെറിയ GPS ഡ്രിഫ്റ്റ് ഓഡോമീറ്ററിനെ വീർപ്പിക്കുന്നില്ല - odometerAccuracyThreshold (സ്ഥിര 50 m) എന്നതിനേക്കാൾ മോശമായ പരിഹാരങ്ങൾ ദൂരത്തിൽ നിന്ന് ഒഴിവാക്കിയിരിക്കുന്നു.

ബാറ്ററി ഉപയോഗം ഇനിയും കുറയ്ക്കുന്നത് എങ്ങനെ?

നിശ്ചലമായിരിക്കുമ്പോൾ ട്രാക്ക്‌ലെറ്റ് ഇതിനകം തന്നെ GPS ഉറങ്ങുന്നു, എന്നാൽ നിങ്ങൾക്ക് നിരവധി ലിവറുകൾ ഉണ്ട്:

ബാറ്ററി ബജറ്റ് — GeoConfig-ൽ batteryBudgetPerHour സജ്ജീകരിച്ചു (ഉദാ. 3.0 3%/hr). ട്രാക്ക്ലെറ്റ് പിന്നീട് distanceFilter, desiredAccuracy എന്നിവ റൺടൈമിൽ സ്വയമേവ ക്രമീകരിക്കുന്നു.
Wakelock release — AndroidConfig-ൽ releaseWakelockWhenStationary: true സജ്ജമാക്കുക, ഉപയോക്താവ് നിശ്ചലമായിരിക്കുമ്പോൾ CPU പൂർണ്ണമായി ഉറങ്ങാൻ അനുവദിക്കുക (MotionDetectionMode.smart ആവശ്യമാണ്).
ദൂര ഫിൽട്ടർ — ഒരു വലിയ distanceFilter (മീറ്റർ) നീങ്ങുമ്പോൾ കുറച്ച് പരിഹാരങ്ങൾ രേഖപ്പെടുത്തുന്നു.
കുറവ് കൃത്യത — desiredAccuracy of medium/low high/best എന്നതിനേക്കാൾ കുറവ് പവർ എടുക്കുന്നു.
ആനുകാലിക മോഡ് — “ഏകദേശം അവർ എവിടെയാണ്” എന്നതിന്, ആനുകാലിക ഒറ്റത്തവണ പരിഹാരങ്ങൾ (startPeriodic) തുടർച്ചയായ ട്രാക്കിംഗിനെക്കാൾ വളരെ വിലകുറഞ്ഞതാണ്.
ചലനാനുമതി നൽകി സൂക്ഷിക്കുക — ACTIVITY_RECOGNITION Tracelet ഇല്ലാതെ GPS-നെ അത്രയും ആക്രമണാത്മകമായി ഉറങ്ങാൻ കഴിയില്ല.

`motionDetectionMode` ഓപ്ഷനുകൾ തമ്മിലുള്ള വ്യത്യാസം എന്താണ്?

GPS ആരംഭിക്കുന്നതിനോ നിർത്തുന്നതിനോ ട്രാക്ക്ലെറ്റ് എങ്ങനെ ചലനം കണ്ടെത്തുമെന്ന് motionDetectionMode തീരുമാനിക്കുന്നു:

accelerometer — ഹാർഡ്‌വെയർ മോഷൻ സെൻസറുകൾ ഉപയോഗിക്കുന്നു (അനുവദിച്ചിട്ടുള്ള പ്രവർത്തന തിരിച്ചറിയലും). ഏറ്റവും കുറഞ്ഞ പവർ, വീടിനകത്തും ജിപിഎസ് പരിഹാരമില്ലാതെയും പ്രവർത്തിക്കുന്നു.
speed — GPS വേഗത മാത്രം ഉപയോഗിക്കുന്നു. ലളിതവും പ്രവചിക്കാവുന്നതുമാണ്, എന്നാൽ നിങ്ങൾ നിർത്തിയതായി ശ്രദ്ധിക്കുന്നതിന് ഇതിന് ഒരു ജിപിഎസ് പരിഹാരം ആവശ്യമാണ്, അതിനാൽ ഇത് പതുക്കെ പ്രതികരിക്കുകയും കൂടുതൽ ശക്തി ഉപയോഗിക്കുകയും ചെയ്യുന്നു.
smart — രണ്ടും സംയോജിപ്പിക്കുന്നു: ഒന്നുകിൽ ആക്‌സിലറോമീറ്റർ അല്ലെങ്കിൽ GPS സ്പീഡ് നിങ്ങൾ നീങ്ങുകയാണെന്ന് പറഞ്ഞാൽ അത് തുടർച്ചയായ ട്രാക്കിംഗിൽ തുടരും, നിങ്ങൾ നിർത്തിയെന്ന് രണ്ടും സമ്മതിക്കുമ്പോൾ മാത്രമേ അത് നിശ്ചലമാകൂ. തെറ്റായ പരിവർത്തനങ്ങൾക്കെതിരെ ഏറ്റവും ശക്തമാണ്; മിക്ക ആപ്പുകൾക്കും ശുപാർശ ചെയ്യുന്നത്.

ലൊക്കേഷൻ സേവനങ്ങളും ട്രാക്കിംഗ് അവസ്ഥങ്ങളും

ട്രാക്കിംഗ് സജീവമായിരിക്കുമ്പോൾ ഉപയോക്താവ് ലൊക്കേഷൻ സേവനങ്ങൾ ഓഫാക്കിയാൽ എന്ത് സംഭവിക്കും?

ചെറിയ ഉത്തരം: Tracelet ട്രാക്കിംഗ് നിർത്തുകയോ ക്രാഷ് ചെയ്യുകയോ കീറുകയോ ചെയ്യില്ല. ഇത് ട്രാക്കിംഗ് സെഷനെ സായുധമായി നിലനിർത്തുന്നു, ഒരു providerchange ഇവൻ്റ് പുറപ്പെടുവിക്കുന്നു, അതുവഴി നിങ്ങളുടെ ആപ്പിന് പ്രതികരിക്കാനാകും, ലൊക്കേഷൻ ഓഫായിരിക്കുമ്പോൾ പുതിയ ലൊക്കേഷനുകളൊന്നും രേഖപ്പെടുത്തില്ല (ചുവടെ രണ്ട് പ്ലാറ്റ്‌ഫോം പ്രത്യേക ഒഴിവാക്കലുകളോടെ), കൂടാതെ യാന്ത്രികമായി പുനരാരംഭിക്കുന്നു ഉപയോക്താവ് ലൊക്കേഷൻ വീണ്ടും പ്രവർത്തനക്ഷമമാക്കുന്ന നിമിഷം - എല്ലാ അവസ്ഥങ്ങളിലും (ഫോർഗ്രൗണ്ട്, പശ്ചാത്തലം, അവസാനിപ്പിച്ചത്). നിങ്ങൾ അല്ല വീണ്ടും start()-ലേക്ക് വിളിക്കേണ്ടതില്ല.

“ലൊക്കേഷൻ സേവനങ്ങൾ ഓഫ്” ഇവിടെ അർത്ഥമാക്കുന്നത് OS-ലെവൽ ലൊക്കേഷൻ ടോഗിൾ എന്നാണ് (Android: ക്രമീകരണങ്ങൾ → ലൊക്കേഷൻ; iOS: ക്രമീകരണങ്ങൾ → സ്വകാര്യത → ലൊക്കേഷൻ സേവനങ്ങൾ). ആപ്പിൻ്റെ അനുമതി റദ്ദാക്കുന്നത് ബന്ധപ്പെട്ടതും എന്നാൽ വേറിട്ടതുമായ ഒരു കേസാണ് - ഈ ഉത്തരത്തിൻ്റെ അവസാനത്തിലുള്ള കുറിപ്പ് കാണുക.

അത് എങ്ങനെ കണ്ടുപിടിക്കാം


final sub = tl.Tracelet.onProviderChange((tl.ProviderChangeEvent e) {
  if (!e.enabled) {
    // Location services were turned OFF — prompt the user / show a banner.
  } else {
    // Back ON — Tracelet has already resumed; no action required.
  }
});

ProviderChangeEvent enabled, status (അംഗീകാരം), gps, network, accuracyAuthorization, gpsFallback, mockLocationsDetected എന്നിവ വഹിക്കുന്നു. അതേ ഇവൻ്റ് പശ്ചാത്തലത്തിൽ/കൊല്ലപ്പെട്ട അവസ്ഥയിലെ തലയില്ലാത്ത കോൾബാക്കിലേക്ക് ഡെലിവർ ചെയ്യപ്പെടും (രജിസ്റ്റർ ചെയ്തിട്ടുണ്ടെങ്കിൽ) കൂടാതെ നിങ്ങൾ disableProviderChangeRecord: true സജ്ജീകരിക്കാത്ത പക്ഷം providerchange റെക്കോർഡായി അത് നിലനിൽക്കും.

അവസ്ഥവും പ്ലാറ്റ്‌ഫോമും അനുസരിച്ച് പെരുമാറ്റം

അവസ്ഥ	ആൻഡ്രോയിഡ്	iOS
മുന്നിൽ	`providerchange` (`enabled: false`) തീപിടുത്തങ്ങൾ; മുൻവശത്തെ സേവനം സജീവമായി തുടരുന്നു; വീണ്ടും പ്രവർത്തനക്ഷമമാക്കുന്നത് വരെ പുതിയ പരിഹാരങ്ങളൊന്നുമില്ല.	`providerchange` തീപിടുത്തങ്ങൾ; `didFailWithError` ഭംഗിയായി കൈകാര്യം ചെയ്യുന്നു (ഒറ്റ ഷോട്ടുകൾ അവസാനം അറിയപ്പെടുന്ന സ്ഥലത്തേക്ക് മടങ്ങുന്നു); പുതിയ പരിഹാരങ്ങളൊന്നുമില്ല.
പശ്ചാത്തലം	ഫോർഗ്രൗണ്ട് സേവനം (അതിൻ്റെ അറിയിപ്പും) പ്രവർത്തിക്കുന്നത് തുടരുന്നു; സംയോജിപ്പിച്ച അപ്‌ഡേറ്റുകൾ നിർത്തുക; `providerchange` ഇപ്പോഴും അയച്ചു. വീണ്ടും പ്രവർത്തനക്ഷമമാക്കുമ്പോൾ പുനരാരംഭിക്കുന്നു.	`CLLocationManager` സബ്‌സ്‌ക്രിപ്‌ഷൻ രജിസ്റ്റർ ചെയ്‌തിരിക്കുന്നു; ലൊക്കേഷൻ തിരികെ നൽകുന്നതുവരെ iOS ഒന്നും നൽകില്ല, തുടർന്ന് പുനരാരംഭിക്കും (കൂടാതെ റീജിയൻ/എസ്എൽസി വഴി ആപ്പ് വീണ്ടും സമാരംഭിക്കാനാകും).
അവസാനിപ്പിച്ചു (കൊല്ലപ്പെട്ടു)	ഒരു പശ്ചാത്തലം/ബൂട്ട് സെഷൻ സജീവമാണെങ്കിൽ (`stopOnTerminate: false` / `startOnBoot`), സേവനം മുകളിൽ പശ്ചാത്തലം ആയി പ്രവർത്തിക്കുന്നു. പ്രക്രിയ സജീവമല്ലെങ്കിൽ, OS അടുത്തത് ആരംഭിക്കുന്നത് വരെ ഒന്നും പ്രവർത്തിക്കില്ല.	കാര്യമായ ലൊക്കേഷൻ / മേഖല നിരീക്ഷണം വഴി iOS ആപ്പ് വീണ്ടും സമാരംഭിക്കുന്നു ഒരു ലൊക്കേഷൻ/മേഖല ഇവൻ്റ് സംഭവിക്കുമ്പോൾ - ലൊക്കേഷൻ ഓഫായിരിക്കുമ്പോൾ അതിന് കഴിയില്ല. വീണ്ടും പ്രവർത്തനക്ഷമമാക്കിയാൽ, അടുത്ത യോഗ്യതാ ഇവൻ്റ് വീണ്ടും സമാരംഭിക്കുകയും പുനരാരംഭിക്കുകയും ചെയ്യുന്നു.

എല്ലാ സാഹചര്യങ്ങളിലും സെഷൻ നില സംരക്ഷിച്ചിരിക്കുന്നു, അതിനാൽ ലൊക്കേഷൻ വീണ്ടും പ്രവർത്തനക്ഷമമാക്കുന്നത് വീണ്ടും ആരംഭിക്കാതെ തന്നെ ട്രാക്കിംഗ് സ്വയമേവ പുനരാരംഭിക്കുന്നു.

എന്താണ് Tracelet * ചെയ്യാത്തത്

ഇത് സെഷൻ യാന്ത്രികമായി നിർത്തുകയോ നിങ്ങളുടെ കോൺഫിഗറേഷൻ/സ്റ്റേറ്റ് മായ്‌ക്കുകയോ ചെയ്യില്ല.
ഇത് ** എറിയുകയോ ക്രാഷ് ചെയ്യുകയോ ചെയ്യുന്നില്ല - പ്ലാറ്റ്‌ഫോം “ലൊക്കേഷൻ ഓഫ് / ഡിസെഡ്” പിശക് പിടിക്കപ്പെട്ടു.
ഇത് അല്ല ലൊക്കേഷനുകൾ കെട്ടിച്ചമയ്ക്കുന്നില്ല (ആൻഡ്രോയിഡ് ഡെഡ് റെക്കണിംഗ് ഒഴികെ, താഴെ) - നിങ്ങളുടെ ഡിബിക്ക് ലൊക്കേഷൻ ഓഫായിരുന്ന കാലയളവിന് ഒരു വിടവുണ്ട്.

അറിഞ്ഞിരിക്കേണ്ട പ്ലാറ്റ്‌ഫോം പ്രത്യേകതകൾ

Android — ഉപയോക്താവ് GPS പ്രവർത്തനരഹിതമാക്കിയെങ്കിലും Wi-Fi/സെൽ പൊസിഷനിംഗ് ഓണാണെങ്കിൽ, Tracelet സ്വയമേവ പവർ പൊസിഷനിംഗിലേക്ക് മടങ്ങുന്നു gpsFallback: true ഉപയോഗിച്ച് providerchange പുറപ്പെടുവിക്കുകയും GPS തിരികെ വരുമ്പോൾ പൂർണ്ണ കൃത്യത പുനഃസ്ഥാപിക്കുകയും ചെയ്യുന്നു. ആ ഏകദേശ പരിഹാരങ്ങൾ *** രേഖപ്പെടുത്തുകയും സമന്വയിപ്പിക്കുകയും ചെയ്യുന്നു (locationSource എന്നതും അവയുടെ യഥാർത്ഥ accuracy എന്നതും ടാഗ് ചെയ്‌തിരിക്കുന്നു). enableDeadReckoning: true ആണെങ്കിൽ, കോൺഫിഗർ ചെയ്‌ത കാലതാമസത്തിന് GPS നഷ്‌ടമായതിന് ശേഷം, ഒരു യഥാർത്ഥ പരിഹാരം വരുന്നതുവരെ ചലന സെൻസറുകളിൽ നിന്ന് Tracelet സ്ഥാനങ്ങൾ കണക്കാക്കുന്നു. സ്ഥിരമായ അറിയിപ്പ് ഉടനീളം ദൃശ്യമാകും.

iOS — പരാജയപ്പെട്ട requestLocation(), സ്റ്റക്ക് ആകുന്നതിന് പകരം അവസാനമായി അറിയപ്പെടുന്ന ലൊക്കേഷൻ ഉപയോഗിച്ച് ഒറ്റത്തവണ അഭ്യർത്ഥനകൾ പരിഹരിക്കുന്നു. ലൊക്കേഷൻ ഓഫായിരിക്കുമ്പോൾ iOS പശ്ചാത്തലമൊന്നും നൽകുന്നില്ല അല്ലെങ്കിൽ ഇവൻ്റുകൾ വീണ്ടും സമാരംഭിക്കുന്നില്ല; ഡെലിവറി, കൽഡ്-സ്റ്റേറ്റ് റീലോഞ്ച് എന്നിവ വീണ്ടും ഓണാക്കിക്കഴിഞ്ഞാൽ പുനരാരംഭിക്കും.

നിങ്ങളുടെ ആപ്പിൽ എന്താണ് ചെയ്യേണ്ടത്

onProviderChange-ലേക്ക് സബ്‌സ്‌ക്രൈബ് ചെയ്‌ത് enabled == false ആകുമ്പോൾ ഒരു ബാനർ/ഡയലോഗ് പ്രദർശിപ്പിക്കുക.
Tracelet.openLocationSettings() വഴി ഉപയോക്താവിനെ ക്രമീകരണങ്ങളിലേക്ക് ഓപ്ഷണലായി നയിക്കുക.
വീണ്ടും പ്രവർത്തനക്ഷമമാക്കുമ്പോൾ start()-ലേക്ക് വീണ്ടും അരുത് വിളിക്കുക - ട്രേസ്‌ലെറ്റ് സ്വന്തമായി പുനരാരംഭിക്കുന്നു; start() എന്ന് വിളിക്കുന്നത് നിരുപദ്രവകരവും എന്നാൽ അനാവശ്യവുമാണ്.

ആപ്പിൻ്റെ അനുമതി അസാധുവാക്കുന്നു, ടോഗിൾ ഓഫാക്കുന്നു

ടോഗിൾ ഓഫാക്കുന്നത് എല്ലാ ആപ്പുകളേയും ബാധിക്കുകയും മുകളിൽ പറഞ്ഞതുപോലെ പൂർണ്ണമായി വീണ്ടെടുക്കുകയും ചെയ്യും. ആപ്പിൻ്റെ ലൊക്കേഷൻ അനുമതി റദ്ദാക്കുന്നത് (അല്ലെങ്കിൽ “എല്ലായ്‌പ്പോഴും” → “ഉപയോഗത്തിലായിരിക്കുമ്പോൾ” തരംതാഴ്ത്തുന്നത്) status / accuracyAuthorization ഫീൽഡുകളിലൂടെ അതേ providerchange ഇവൻ്റ് വഴി റിപ്പോർട്ട് ചെയ്യുന്നു. ആൻഡ്രോയിഡ് 12+-ൽ, പശ്ചാത്തല-ലൊക്കേഷൻ അനുമതി നഷ്‌ടപ്പെട്ടാൽ, ഒരു ബൂട്ട്/പശ്ചാത്തല പുനരാരംഭിക്കൽ മനഃപൂർവം ഒഴിവാക്കപ്പെടും (അത് നിശ്ശബ്ദമായി പരാജയപ്പെടും) - അനുമതി വീണ്ടും നൽകി പുനരാരംഭിക്കാൻ വീണ്ടും ആരംഭിക്കുക.

ലൊക്കേഷനുകൾ എത്രത്തോളം കൃത്യമാണ്, വൈഫൈ/സെൽ ഫിക്സുകളിൽ നിന്ന് ഞാൻ എങ്ങനെയാണ് GPS-നോട് പറയുന്നത്?

ഓരോ Location-ലും മീറ്ററിൽ ഒരു യഥാർത്ഥ coords.accuracy ഉണ്ട് കൂടാതെ locationSource ടാഗും ഉണ്ട്: "gps" (≤50 m), "wifi" (≤200 m), "cell" (മോശം), അല്ലെങ്കിൽ "network" (GPS ഫാൾബാക്ക് സമയത്ത്). ട്രെയ്‌സ്‌ലെറ്റ് നിശ്ശബ്ദമായി കൃത്യത കുറഞ്ഞ പരിഹാരങ്ങൾ ഉപേക്ഷിക്കുന്നില്ല - അത് അവ രേഖപ്പെടുത്തുന്നു, അതിനാൽ നിങ്ങളുടെ ട്രയൽ തുടർച്ചയായി നിലനിൽക്കും - എന്നാൽ ഇത് **ഓഡോമീറ്ററിൽ നിന്ന് മോശമായ പരിഹാരങ്ങൾ സൂക്ഷിക്കുന്നു (odometerAccuracyThreshold, ഡിഫോൾട്ട് 50 m) കൂടാതെ അസാധ്യമായ വേഗതയുള്ള ജമ്പുകൾ നിരസിക്കുന്നു (maxImpliedSpeed).

നിങ്ങൾക്ക് GPS നിലവാരമുള്ള ഡാറ്റ മാത്രമേ ആവശ്യമുള്ളൂവെങ്കിൽ, locationSource == "gps" അല്ലെങ്കിൽ accuracy <= 50 ഉപയോഗിച്ച് നിങ്ങളുടെ വശത്ത് ഫിൽട്ടർ ചെയ്യുക. ഉപയോക്താവ് ഏകദേശം/കഷ്ടം ലൊക്കേഷൻ (അല്ലെങ്കിൽ iOS “കൃത്യമായത്: ഓഫ്”) മാത്രമേ അനുവദിച്ചിട്ടുള്ളൂവെങ്കിൽ, എല്ലാ പരിഹാരങ്ങളും OS പോളിസി പ്രകാരം ഏകദേശമാണ് - accuracyAuthorization / reducedAccuracy പരിശോധിക്കുക.

എൻ്റെ ട്രാക്ക് നടക്കുമ്പോൾ ഇടത്തോട്ടും വലത്തോട്ടും കുതിക്കുന്നു, ദൂരം സ്ട്രാവയെക്കാൾ 2-3 മടങ്ങ് കൂടുതലാണ്. ഞാനത് എങ്ങനെ ശരിയാക്കും?

ജിപിഎസ് ശബ്‌ദം യഥാർത്ഥ ചലനമായി രേഖപ്പെടുത്തുന്നു. നടത്ത വേഗതയിൽ (~1.4 മീ/സെ) ഒരു ഹാൻഡ്‌സെറ്റിൻ്റെ തിരശ്ചീന പിശക് തുറന്ന ആകാശത്തിന് കീഴിൽ 5-8 മീറ്ററാണ്, മരത്തിൻ്റെ മറയ്‌ക്കോ കെട്ടിടങ്ങൾക്കുമിടയിലോ വളരെ മോശമാണ് - ഉപയോക്താവ് യഥാർത്ഥത്തിൽ രണ്ട് പരിഹാരങ്ങൾക്കിടയിൽ എത്ര ദൂരം നീങ്ങി എന്നതിൻ്റെ വലിയൊരു ഭാഗം. സൈഡിലേക്കുള്ള ഓരോ വിറയലും “സ്പൈക്ക്” ഒരു യഥാർത്ഥ കോർഡിനേറ്റ് മാറ്റമാണ്, കൂടാതെ എല്ലാ പരിഹാരങ്ങളെയും വിശ്വസിക്കുന്ന ഒരു ഓഡോമീറ്റർ അതെല്ലാം ചേർക്കുന്നു. ഫിറ്റ്‌നസ് ആപ്പുകൾ ഓൺ-ഫൂട്ട് കേസിനായി പ്രത്യേകം ട്യൂൺ ചെയ്യുന്നതിനാൽ അവ സുഗമമായി കാണപ്പെടുന്നു; വാഹനങ്ങൾ, സൈക്കിൾ യാത്രക്കാർ, കാൽനടയാത്രക്കാർ എന്നിവരിലുടനീളം SDK ഡിഫോൾട്ടുകൾ മനഃപൂർവ്വം നിഷ്പക്ഷമാണ്.

ആദ്യം, 3.8.0-beta-ലേക്കോ അതിനുശേഷമുള്ളതിലേക്കോ അപ്‌ഗ്രേഡ് ചെയ്യുക. 3.7.6-ലേക്കോ അതിനു താഴെയോ ഉള്ള രണ്ട് വൈകല്യങ്ങൾ കൃത്യമായി ഈ ലക്ഷണം ഉളവാക്കിയതിനാൽ അത് ക്രമീകരിക്കാൻ കഴിഞ്ഞില്ല:

useKalmanFilter: true റെൻഡർ ചെയ്‌ത ട്രാക്ക് മാത്രം മിനുസപ്പെടുത്തി. ലൊക്കേഷൻ പ്രോസസറിന് ശേഷം സ്മൂത്തിംഗ് പ്രവർത്തിക്കുകയും coords മാത്രം നൽകുകയും ചെയ്‌തു, അതിനാൽ ഓഡോമീറ്റർ അസംസ്‌കൃത ജിട്ടർ സംയോജിപ്പിച്ചുകൊണ്ടിരുന്നു - ദൂരം തെറ്റായി തുടരുമ്പോൾ മാപ്പ് വൃത്തിയായി കാണപ്പെട്ടു. ഇത് ഇപ്പോൾ ഫിൽട്ടറുകൾക്ക് മുമ്പ് ** പ്രവർത്തിക്കുന്നു, അതിനാൽ ദൂരം, കൃത്യത/ഇംപ്ലിഡ്-സ്പീഡ് ഗേറ്റുകൾ, ഓഡോമീറ്റർ എന്നിവയെല്ലാം ഡി-നോയിസ്ഡ് ട്രാക്ക് കാണുന്നു. അപ്‌ഗ്രേഡ് ചെയ്‌തതിന് ശേഷം നിങ്ങളുടെ റെക്കോർഡ് ചെയ്‌ത ദൂരം കുറയുമെന്ന് പ്രതീക്ഷിക്കുക; ആ ഡ്രോപ്പ് നിങ്ങൾ മുമ്പ് എണ്ണിയിരുന്ന ശബ്ദമാണ്.
odometerAccuracyThreshold എന്നതിനായുള്ള വളരെ പരുക്കനായ ഒരു ഫിക്സ് ഓഡോമീറ്ററിൽ നിന്ന് ശരിയായി സൂക്ഷിച്ചിരിക്കുന്നു, എന്നാൽ ഓഡോമീറ്ററിൻ്റെ റഫറൻസ് പോയിൻ്റ് എന്തായാലും അതിലേക്ക് മുന്നേറി - അതിനാൽ ആ സെഗ്‌മെൻ്റിൽ മൂടിയ നിലം ശാശ്വതമായി നഷ്ടപ്പെട്ടു. ഗേറ്റ് മുറുകിയാൽ അത് ശരിയാക്കുന്നതിനുപകരം ദൂരം കാണാതെ പോയി. ഒരു പരുക്കൻ പരിഹാരം ഇപ്പോൾ മാറ്റിവയ്ക്കുന്നു അതിൻ്റെ ദൂരം, അടുത്ത വിശ്വസനീയമായ ഫിക്സ് മുഴുവൻ സ്പാൻ ബുക്ക്.

അപ്പോൾ പരിധികൾ ഊഹിക്കുന്നത് നിർത്തുക — ഉപകരണത്തിലെ ക്ലാസിഫയർ അവ തിരഞ്ഞെടുക്കട്ടെ:


await tl.Tracelet.ready(tl.Config(
  geo: tl.GeoConfig(
    filter: tl.LocationFilter(useKalmanFilter: true),
  ),
  classifier: tl.ClassifierConfig(
    enableFusedClassifier: true,      // required — the classifier must be running
    autoTuneFromTransportMode: true,
  ),
));

still / walking / running / cycling / vehicle എന്നിവ വേർതിരിക്കുന്നതിന് ക്ലാസിഫയർ ആക്സിലറോമീറ്റർ കേഡൻസിനെ GPS വേഗതയിൽ സംയോജിപ്പിക്കുന്നു, കൂടാതെ ഒരു മോഡ് കമ്മിറ്റ് ചെയ്യുമ്പോൾ അത് distanceFilter, trackingAccuracyThreshold, odometerAccuracyThreshold, odometerAccuracyThreshold, എന്നിവയ്‌ക്ക് അനുയോജ്യമായ മൂല്യങ്ങളിലേക്ക് മാറുകയും ചെയ്യുന്നു. ഗ്യാരണ്ടികൾക്കായി ട്രാൻസ്‌പോർട്ട് മോഡ് വഴി യാന്ത്രിക-ട്യൂണിംഗ് കാണുക (പ്രതിജ്ഞാബദ്ധമായ മാറ്റങ്ങൾ മാത്രം, പരിധികൾ മാറ്റിസ്ഥാപിച്ചതിനാൽ ഓഡോമീറ്റർ തുടർച്ചയായി തുടരും, unknown നിങ്ങളുടെ സ്വന്തം മൂല്യങ്ങൾ പുനഃസ്ഥാപിക്കുന്നു).

debug: true, logLevel: verbose എന്നിവ ഉപയോഗിച്ച് നിങ്ങൾ ലോഗിൽ ഓരോ റീട്യൂണും കാണും:


auto-tune: 'walking' → distanceFilter=8.0m trackingAccuracy=15m odometerAccuracy=10m maxImpliedSpeed=4m/s

നടത്തം, ജോഗിംഗ്, ഓട്ടം എന്നിവയ്ക്കായി ശുപാർശ ചെയ്യുന്ന പ്രീസെറ്റുകൾ ഉണ്ടോ?

യാന്ത്രിക-ട്യൂണിംഗ് ബാധകമാകുന്ന കൃത്യമായ മൂല്യങ്ങൾ ഇവയാണ്, അതിനാൽ നിങ്ങളുടെ ആപ്പ് എപ്പോഴെങ്കിലും ഒരു പ്രവർത്തനം (റൺ-ട്രാക്കർ, ഡെലിവറി-ഓൺ-ഫൂട്ട് ആപ്പ്) ട്രാക്ക് ചെയ്യുകയാണെങ്കിൽ നിങ്ങൾക്ക് അവ കൈകൊണ്ട് സജ്ജീകരിക്കാനാകും, നിങ്ങൾ ക്ലാസിഫയർ റൺ ചെയ്യുന്നില്ല:

പ്രവർത്തനങ്ങൾ	`distanceFilter`	നോട്ട്രാൻസ്1ലേറ്റ്	`odometerAccuracyThreshold`	നോട്രാൻസ്3ലേറ്റ്
നിശ്ചലമായ	25 മീറ്റർ	15 മീറ്റർ	10 മീറ്റർ	3 m/s
നടത്തം	8 മീറ്റർ	15 മീറ്റർ	10 മീറ്റർ	4 m/s
ജോഗിംഗ് / ഓട്ടം	12 മീറ്റർ	25 മീറ്റർ	15 മീറ്റർ	9 m/s
സൈക്ലിംഗ്	20 മീറ്റർ	30 മീറ്റർ	20 മീറ്റർ	20 m/s
ഡ്രൈവിംഗ്	30 മീറ്റർ	50 മീറ്റർ	30 മീറ്റർ	60 m/s

ജോഗിംഗ് ഒരു പ്രത്യേക പ്രീസെറ്റ് അല്ല. ഇത് റണ്ണിംഗ് ബാൻഡിനുള്ളിൽ (6-20 km/h) ഇരിക്കുകയും അതിൻ്റെ പരിധികൾ പങ്കിടുകയും ചെയ്യുന്നു - ഓട്ടത്തിൽ നിന്ന് വ്യത്യസ്‌തമായ ഒരു “ജോഗിംഗ് പ്രീസെറ്റ്” കണ്ടുപിടിക്കുന്നത് കൃത്യതയായാണ്, അളക്കലല്ല.

സുഗമമായി നടക്കാൻ മാത്രമുള്ള ഒരു ആപ്പ്:


geo: tl.GeoConfig(
  distanceFilter: 8,
  filter: tl.LocationFilter(
    useKalmanFilter: true,
    trackingAccuracyThreshold: 15,
    odometerAccuracyThreshold: 10,
    maxImpliedSpeed: 4,
  ),
),

നിങ്ങൾ ഇതിനകം കൈകൊണ്ട് ട്യൂൺ ചെയ്‌തിട്ട് ~50% നീളമുണ്ടെങ്കിൽ, ഈ മൂന്ന് കാര്യങ്ങൾ പരിശോധിക്കുക:

GPS നോയിസ് ഫ്ലോറിന് താഴെയുള്ള ഒരു distanceFilter ശബ്‌ദത്തെ ദൂരമായി അംഗീകരിക്കുന്നു. distanceFilter: 5-ൽ, ഒരു നിശ്ചലമായ 6 മീറ്റർ പിശക് 6 മീറ്റർ നടത്തം എന്ന് പറയുന്നു. കാൽനടയായി ~8 മീറ്ററിലോ അതിനുമുകളിലോ സൂക്ഷിക്കുക - അവബോധജന്യമായി, കുറച്ച് പോയിൻ്റുകൾ രേഖപ്പെടുത്തുന്നത് കൂടുതൽ കൃത്യമായ ആകെത്തുക നൽകുന്നു.
ഇറുകിയ trackingAccuracyThreshold ഓഡോമീറ്റർ ഗേറ്റിനെ അപ്രസക്തമാക്കുന്നു. trackingAccuracyThreshold: 10 ഉപയോഗിച്ച്, നിലനിൽക്കുന്ന ഓരോ ഫിക്സും ഇതിനകം ≤ 10 m ആണ്, അതിനാൽ odometerAccuracyThreshold (സ്ഥിര 50 m) ഒരിക്കലും ഒന്നും നിരസിക്കുന്നില്ല. നിങ്ങൾ കണക്കാക്കിയിരുന്ന ഗേറ്റ് ഒന്നും ചെയ്യുന്നില്ല; പിശക് വരുന്നത് നിങ്ങൾ സൂക്ഷിച്ചിട്ടുള്ള തിരുത്തലുകളിൽ നിന്നാണ്, നിങ്ങൾ ഉപേക്ഷിച്ചവയല്ല.
useKalmanFilter ഡിഫോൾട്ടായി ഓഫാണ്, 3.8.0-ന് മുമ്പ് അത് ഓണായിരിക്കുമ്പോൾ പോലും ദൂരത്തെ ബാധിക്കില്ല.

മറ്റൊരു ആപ്പുമായി കൃത്യമായ പൊരുത്തം പ്രതീക്ഷിക്കരുത്. Strava, Google Fit, Tracelet എന്നിവ വ്യത്യസ്‌ത ഫിക്സ് സ്ട്രീമുകൾ (സാമ്പിൾ കാഡൻസ്, പ്രൊവൈഡർ ക്രമീകരണങ്ങൾ, ആപ്പ് ഫോർഗ്രൗണ്ട് ചെയ്‌തിരുന്നോ എന്നത്) ഉപയോഗിക്കുകയും വ്യത്യസ്ത സ്മൂത്തിംഗ് പ്രയോഗിക്കുകയും ചെയ്യുന്നു. അറിയപ്പെടുന്ന ദൈർഘ്യമുള്ള റൂട്ടിൽ ഏതാനും ശതമാനത്തിനുള്ളിലെ ഉടമ്പടിയാണ് റിയലിസ്റ്റിക് ടാർഗെറ്റ് - നിങ്ങൾക്ക് പരിശോധിച്ചുറപ്പിക്കാൻ കഴിയുന്ന ഒരു റൂട്ടിനെ അളക്കുക, മറ്റൊരു ആപ്പിൻ്റെ നമ്പറിന് എതിരല്ല.

`getCurrentPosition()` ചില ഫോണുകളിൽ `LOCATION_FAILURE` ഉപയോഗിച്ച് പരാജയപ്പെടുകയും മറ്റുള്ളവയിൽ പ്രവർത്തിക്കുകയും ചെയ്യുന്നത് എന്തുകൊണ്ട്?

PlatformException(LOCATION_FAILURE, "Failed to obtain location") അർത്ഥമാക്കുന്നത് ഒറ്റത്തവണ അഭ്യർത്ഥനയ്ക്ക് timeout-നുള്ളിൽ ഒരു പുതിയ പരിഹാരം നേടാനായില്ല, കൂടാതെ എന്നതിലേക്ക് മടങ്ങാൻ കാഷെ ചെയ്‌ത ലൊക്കേഷൻ ഇല്ലായിരുന്നു. ഇത് നിങ്ങളുടെ കോഡിലെ ഒരു ബഗ് അല്ല - ഉപകരണത്തിൻ്റെ GPS/ഫ്യൂസ്ഡ് സ്റ്റാക്ക് സമയബന്ധിതമായി പരിഹരിക്കുന്നതിൽ പരാജയപ്പെടുന്നു. ഉയർന്ന കൃത്യതയുള്ള ഒരു ഷോട്ട് ഒരു പുതിയ പരിഹാരത്തിനായി ആവശ്യപ്പെടുന്നു, അത് 30 സെക്കൻഡിനുള്ളിൽ വിജയിക്കുമോ എന്നത് ഉപകരണത്തെയും പരിസ്ഥിതിയെയും ആശ്രയിച്ചിരിക്കുന്നു:

“Google ലൊക്കേഷൻ കൃത്യത” ഓഫാണ് — ക്രമീകരണങ്ങൾ → ലൊക്കേഷൻ → ലൊക്കേഷൻ സേവനങ്ങൾ → Google ലൊക്കേഷൻ കൃത്യത (Wi-Fi/Bluetooth സ്കാനിംഗ്). ഓണായിരിക്കുമ്പോൾ, ഫ്യൂസ് ചെയ്‌ത ദാതാവ് ഏതാണ്ട് തൽക്ഷണം ഒരു വൈഫൈ/സെൽ ഫിക്സ് ഇൻഡോർ നൽകുന്നു; ഓഫായിരിക്കുമ്പോൾ, ഒരിക്കലും വീടിനുള്ളിൽ എത്താത്ത ഒരു റോ ജിപിഎസ് പരിഹാരത്തിനായി ഫോൺ കാത്തിരിക്കണം. ഇതാണ് “എൻ്റെ ഫോണിൽ പ്രവർത്തിക്കുന്നത്, അവരുടെതല്ല” എന്നതിൻ്റെ #1 കാരണം
വീടിനുള്ളിൽ / അണ്ടർഗ്രൗണ്ട് / സ്കൈ വ്യൂ ഇല്ല — ഒരു തണുത്ത ജിപിഎസ് ഫിക്സിന് സ്കൈ വിസിബിലിറ്റി ആവശ്യമാണ്, കൂടാതെ ഫ്ലാഗ്ഷിപ്പുകൾക്ക് നിമിഷങ്ങൾക്കുള്ളിൽ ജിപിഎസ് പരിഹാരങ്ങൾ ലഭിക്കുമ്പോൾ, ഒരു തണുത്ത ഫസ്റ്റ് ഫിക്സിനായി (TTFF) ബജറ്റ് ചിപ്സെറ്റുകൾക്ക് 30 സെക്കൻഡ് കവിയാൻ കഴിയും.
GPS പ്രൊവൈഡർ OS തലത്തിൽ പ്രവർത്തനരഹിതമാക്കി (നെറ്റ്‌വർക്ക്-മാത്രം ലൊക്കേഷൻ) — ശുദ്ധമായ ഉയർന്ന കൃത്യതയുള്ള അഭ്യർത്ഥനയിൽ ലോക്ക് ചെയ്യാൻ ഒന്നുമില്ല.
Google Play സേവനങ്ങൾ നഷ്‌ടമായി/കാലഹരണപ്പെട്ടതാണ് (ചില Huawei/AOSP ബിൽഡുകൾ) — ഫ്യൂസ് ചെയ്‌ത ക്ലയൻ്റ് പ്രവർത്തിപ്പിക്കാൻ കഴിയില്ല.
സാമ്പിൾ എണ്ണം - samples: 3 ട്രേസ്‌ലെറ്റ് ഉപയോഗിച്ച് മൂന്ന് പരിഹാരങ്ങൾ ശേഖരിക്കണം; നാമമാത്രമായ സിഗ്നലിൽ, അത് ഒന്ന് ലഭിക്കുകയും ബാക്കിയുള്ളവയ്ക്ക് മുമ്പ് സമയം അവസാനിക്കുകയും ചെയ്യും. samples: 1 വീടിനുള്ളിൽ കൂടുതൽ ക്ഷമിക്കുന്നു.

ഇത് എങ്ങനെ വിശ്വസനീയമാക്കാം - അവസാനം അറിയപ്പെടുന്ന സ്ഥലത്തേക്ക് മടങ്ങുക:


Future<tl.Location?> bestPosition() async {
  try {
    return await tl.Tracelet.getCurrentPosition(
      desiredAccuracy: tl.DesiredAccuracy.high,
      timeout: 60,        // cold GPS fixes on budget phones can exceed 30 s
      samples: 1,         // more forgiving indoors than 3
      maximumAge: 30000,  // accept a <30 s-old cached fix instantly
    );
  } on PlatformException catch (e) {
    if (e.code == 'LOCATION_FAILURE') {
      // Weak/indoor signal — fall back to the cached fix before giving up.
      return await tl.Tracelet.getLastKnownLocation();
    }
    rethrow;
  }
}

GPS ഉണർത്താതെ തന്നെ maximumAge അടുത്തിടെ കാഷെ ചെയ്‌ത പരിഹാരം നൽകുന്നു - ഹാജർ/ചെക്ക്-ഇൻ എന്നിവയ്‌ക്ക് 30 സെക്കൻഡ് പഴയ സ്ഥാനം നല്ലതാണ്.
getLastKnownLocation() ഒരിക്കലും ഒരു ദാതാവിനെ സജീവമാക്കുന്നില്ല, ഒപ്പം സംയോജിപ്പിച്ച കാഷെ കൈവശമുള്ളതെന്തും തിരികെ നൽകുന്നില്ല, അതിനാൽ യഥാർത്ഥമായി ഒന്നും ലഭ്യമല്ലാത്തപ്പോൾ മാത്രമേ നിങ്ങൾ “ദുർബലമായ സിഗ്നൽ” സന്ദേശം കാണിക്കൂ.
ലോഞ്ച് ചെയ്തതിന് ശേഷമുള്ള ആദ്യ പരിഹാരത്തിനായി timeout ഉദാരമായി (45–60 സെക്കൻഡ്) നിലനിർത്തുക, ഇൻഡോർ പരിഹാരങ്ങൾ തുടർച്ചയായി പരാജയപ്പെടുകയാണെങ്കിൽ Google ലൊക്കേഷൻ കൃത്യത പ്രവർത്തനക്ഷമമാക്കാൻ ഉപയോക്താക്കളോട് ആവശ്യപ്പെടുക (getProviderState() / getHealth() വഴി ദാതാവിൻ്റെ അവസ്ഥ കണ്ടെത്തുക).

പശ്ചാത്തലവും അവസാനിപ്പിക്കലും

ആപ്പ് അടയ്‌ക്കുകയോ സ്വൈപ്പ് ചെയ്യുകയോ ചെയ്‌തതിന് ശേഷവും Tracelet ട്രാക്ക് ചെയ്യുന്നുണ്ടോ?

Android — അതെ, stopOnTerminate: false ഉപയോഗിച്ച്. ഉപയോക്താവ് സമീപകാലങ്ങളിൽ നിന്ന് ആപ്പ് സ്വൈപ്പ് ചെയ്യുമ്പോൾ, Flutter എഞ്ചിൻ ആവശ്യമില്ലാത്ത ഒരു നേറ്റീവ് പശ്ചാത്തല സേവനത്തിലേക്ക് ട്രാക്ക് ലെറ്റ് ഹാൻഡ്‌സ് ട്രാക്കുചെയ്യുന്നു, അതിനാൽ ലൊക്കേഷൻ ക്യാപ്‌ചർ ചെയ്യലും സമന്വയവും തുടരും. സ്ഥിരമായ ഫോർഗ്രൗണ്ട്-സർവീസ് അറിയിപ്പാണ് ആ സേവനത്തെ സജീവമായി നിലനിർത്തുന്നത്. stopOnTerminate: true ഉപയോഗിച്ച്, പ്രതീക്ഷിച്ചതുപോലെ സ്വൈപ്പ്-അവേയിൽ ട്രാക്കിംഗ് നിർത്തുന്നു.

iOS — ഇത് ആപ്പ് എങ്ങനെ അടച്ചു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. മെമ്മറി/സിസ്റ്റം കാരണങ്ങളാൽ iOS ആപ്പ് അവസാനിപ്പിക്കുകയാണെങ്കിൽ, അത് അടുത്ത പ്രധാന-ലൊക്കേഷൻ മാറ്റത്തിൽ പശ്ചാത്തലത്തിൽ വീണ്ടും സമാരംഭിക്കുകയും പുനരാരംഭിക്കുകയും ചെയ്യുന്നു. ഉപയോക്താവ്** ആപ്പിൽ നിന്ന് നിർബന്ധിതമായി പുറത്തുകടക്കുകയാണെങ്കിൽ (ആപ്പ് സ്വിച്ചറിൽ സ്വൈപ്പ് ചെയ്യുക), ആപ്പ് വീണ്ടും തുറക്കുന്നത് വരെ iOS അതിൻ്റെ എല്ലാ ലൊക്കേഷൻ സേവനങ്ങളും മനഃപൂർവം താൽക്കാലികമായി നിർത്തുന്നു - ഇത് അസാധുവാക്കാൻ ഒരു SDK-നെയും Apple അനുവദിക്കുന്നില്ല.

ഞാൻ `showNotificationOnPauseOnly: true` സജ്ജീകരിച്ചെങ്കിലും അറിയിപ്പ് എല്ലായ്പ്പോഴും ദൃശ്യമാണ്. എന്തുകൊണ്ട്?

കാരണം stopOnTerminate false ആണ്, കൂടാതെ രണ്ട് ക്രമീകരണങ്ങളും ബഹുമാനിക്കാൻ കഴിയില്ല.

അറിയിപ്പ് മറയ്‌ക്കുക എന്നതിനർത്ഥം ഫോർഗ്രൗണ്ട് സേവനത്തെ തരംതാഴ്ത്തുക എന്നാണ് - അറിയിപ്പില്ലാതെ Android-ന് ഫോർഗ്രൗണ്ട് സേവനമില്ല - കൂടാതെ ഫോർഗ്രൗണ്ട് സേവനമൊന്നും കൈവശം വയ്ക്കാത്ത പ്രക്രിയയാണ് ഉപയോക്താവ് സമീപകാലങ്ങളിൽ നിന്ന് ആപ്പ് സ്വൈപ്പ് ചെയ്യുമ്പോൾ Android ഇല്ലാതാക്കുന്നത്. അതിനാൽ അറിയിപ്പ് മറച്ചിരിക്കുമ്പോൾ, stopOnTerminate: false ഒന്നും ഉറപ്പുനൽകുന്നില്ല: വിടവിനുള്ളിൽ ഒരു സ്വൈപ്പ് ടൈം ചെയ്‌തത് (ഒരു പിക്‌സൽ ഫോൾഡിൽ 285 എംഎസ്, Android 15 ഉപകരണത്തിൽ 700–1500 എംഎസ് അളക്കുന്നു) തലയില്ലാത്ത ടാസ്‌ക്കില്ലാതെ, ഇവൻ്റുകളോ ലോഗുകളോ ഇല്ലാതെ, പ്രക്രിയയെ പൂർണ്ണമായും ഇല്ലാതാക്കി. ടാസ്‌ക്-നീക്കം ചെയ്യൽ സമയത്ത് ഒരു SDK ചെയ്യുന്നതൊന്നും തടയാൻ കഴിയില്ല - ടാസ്‌ക് നീക്കം ചെയ്‌തെന്ന് നിങ്ങളുടെ ആപ്പിനോട് പറയുന്നതിന് മുമ്പ് ഏതൊക്കെ പ്രോസസ്സുകൾ ഇല്ലാതാക്കണമെന്ന് Android ഇതിനകം തിരഞ്ഞെടുത്തിട്ടുണ്ട്.

അതിജീവന വാഗ്ദാനത്തിന് അനുകൂലമായി ട്രേസ്ലെറ്റ് അത് പരിഹരിക്കുന്നു: stopOnTerminate: false ഉപയോഗിച്ച് ഫ്ലാഗ് അവഗണിക്കപ്പെടുകയും അറിയിപ്പ് നിലനിൽക്കുകയും ചെയ്യുന്നു. ലൈഫ് സൈക്കിൾ ചാനലിൽ start()-ന് ഒരിക്കൽ കാരണം രേഖപ്പെടുത്തുന്നു, അതിനാൽ Tracelet.getLogs() അത് കാണിക്കും.

നിങ്ങൾക്ക് മറഞ്ഞിരിക്കുന്ന അറിയിപ്പ് ലഭിക്കാൻ താൽപ്പര്യമുണ്ടെങ്കിൽ stopOnTerminate: true സജ്ജീകരിക്കുക, കൂടാതെ ആപ്പ് സ്വൈപ്പ് ചെയ്യുമ്പോൾ ട്രാക്കിംഗ് അവസാനിക്കുന്നതിൽ സന്തോഷമുണ്ട്. പൂർണ്ണ വിശദീകരണം 📖

ഓഫ്‌ലൈനും സമന്വയവും

ഉപകരണത്തിൽ ഇൻ്റർനെറ്റ് ഇല്ലെങ്കിൽ എൻ്റെ ലൊക്കേഷനുകൾക്ക് എന്ത് സംഭവിക്കും?

ഒന്നും നഷ്‌ടപ്പെടുന്നില്ല. എല്ലാ പരിഹാരങ്ങളും ഉപകരണത്തിലെ ഡാറ്റാബേസിലേക്ക് (encryptDatabase: true ചെയ്യുമ്പോൾ എൻക്രിപ്റ്റ് ചെയ്‌തത്) അത് ക്യാപ്‌ചർ ചെയ്‌ത തൽക്ഷണം - നെറ്റ്‌വർക്കിൽ നിന്ന് സ്വതന്ത്രമായി എഴുതപ്പെടും. എക്‌സ്‌പോണൻഷ്യൽ ബാക്ക്ഓഫ് (maxRetries, retryBackoffBase, retryBackoffCap) ഉപയോഗിച്ച് വീണ്ടും ശ്രമിച്ചുകൊണ്ട് കണക്റ്റിവിറ്റി തിരികെ വരുമ്പോൾ യാന്ത്രിക സമന്വയം അവ അപ്‌ലോഡ് ചെയ്യുന്നു. സെർവർ രസീത് സ്ഥിരീകരിച്ചതിന് ശേഷം ** ഡാറ്റാബേസിൽ നിന്ന് ഒരു ബാച്ച് ഇല്ലാതാക്കപ്പെടും, അതിനാൽ പരാജയപ്പെട്ടതോ തടസ്സപ്പെട്ടതോ ആയ ഒരു അപ്‌ലോഡ് വീണ്ടും ശ്രമിക്കും, ഒരിക്കലും ഉപേക്ഷിക്കില്ല.

നിങ്ങളുടെ നിലനിർത്തൽ പരിധിക്കുള്ളിൽ ലൊക്കേഷനുകൾ ബഫർ ചെയ്യുന്നു (maxDaysToPersist, ഡിഫോൾട്ട് 3 ദിവസം, കൂടാതെ maxRecordsToPersist, ഡിഫോൾട്ടായി അൺലിമിറ്റഡ്); ഏറ്റവും പഴക്കമേറിയവ അവ കവിഞ്ഞാൽ വെട്ടിമാറ്റുന്നു. ആ പരിധി സ്വിച്ച് ഓഫ് ചെയ്യാൻ -1 ആയി സജ്ജീകരിക്കുക - ഡിഫോൾട്ട് വിൻഡോയേക്കാൾ ഓഫ്‌ലൈനിൽ ദീർഘനേരം നീണ്ടുനിൽക്കുമെന്ന് നിങ്ങൾ പ്രതീക്ഷിക്കുന്നുവെങ്കിൽ, മനഃപൂർവം ചെയ്യുന്നത് മൂല്യവത്താണ്, കാരണം നിലനിർത്തൽ വഴി ഡ്രോപ്പ് ചെയ്ത ഒരു റെക്കോർഡ് അപ്‌ലോഡ് ചെയ്തിട്ടില്ല. 3.8.3 ന് മുമ്പ് ഒരു പരിധിയും യഥാർത്ഥത്തിൽ നടപ്പിലാക്കിയിരുന്നില്ല, അതിനാൽ ക്യൂ പരിധിയില്ലാതെ വളർന്നു. disableAutoSyncOnCellular: true ഉപയോഗിച്ച് നിങ്ങൾക്ക് സെല്ലുലാർ അപ്‌ലോഡുകൾ തടഞ്ഞുവയ്ക്കാനും കഴിയും.

ഇൻ്റർനെറ്റ് തിരികെ വരുമ്പോൾ Tracelet_sync സ്വയമേവ എൻ്റെ ബാക്കെൻഡിലേക്ക് തള്ളുമോ?

അതെ, സ്വയമേവ പൂർണ്ണമായും പശ്ചാത്തലത്തിൽ. നിങ്ങൾ tracelet_sync (അല്ലെങ്കിൽ tracelet_supabase / tracelet_firebase പോലുള്ള അതിൻ്റെ റാപ്പറുകൾ) ഉപയോഗിക്കുകയാണെങ്കിൽ, നിങ്ങൾ സ്വയം നെറ്റ്‌വർക്ക്-വീണ്ടും ശ്രമിക്കേണ്ട ലോജിക്കൊന്നും എഴുതേണ്ടതില്ല.

നെറ്റ്‌വർക്ക് കണക്റ്റിവിറ്റി പുനഃസ്ഥാപിച്ചതായി OS കണ്ടെത്തുമ്പോൾ, നേറ്റീവ് സമന്വയ എഞ്ചിൻ പശ്ചാത്തലത്തിൽ ഉടനടി ഉണരുകയും കാഷെ ചെയ്‌ത ലൊക്കേഷനുകൾ കാലാനുസൃത ബാച്ചുകളിൽ നിങ്ങളുടെ ബാക്കെൻഡിലേക്ക് അപ്‌ലോഡ് ചെയ്യാൻ തുടങ്ങുകയും ചെയ്യുന്നു. ലോക്കൽ ഡാറ്റാബേസ് സെർവറുമായി പൂർണ്ണമായി പിടിക്കപ്പെടുന്നതുവരെ ഇത് അപ്‌ലോഡ് ചെയ്യുന്നത് തുടരുന്നു, നീണ്ട ഓഫ്‌ലൈൻ കാലയളവുകൾക്ക് ശേഷവും ഡാറ്റ നഷ്‌ടമാകില്ലെന്ന് ഉറപ്പാക്കുന്നു.

റീബൂട്ട് & ഉപകരണം അൺലോക്ക്

ഒരു റീബൂട്ടിന് ശേഷം, ഞാൻ ഉപകരണം അൺലോക്ക് ചെയ്യുന്നതിന് മുമ്പ് Tracelet ട്രാക്ക് ചെയ്യാൻ തുടങ്ങുമോ?

ഇല്ല — ട്രെയ്‌സ്‌ലെറ്റ് പുനരാരംഭിക്കുന്നതിന് മുമ്പ് റീബൂട്ട് ചെയ്‌തതിന് ശേഷം ഉപകരണം ഒരിക്കലെങ്കിലും അൺലോക്ക് ചെയ്‌തിരിക്കണം. ഇതൊരു Android പ്ലാറ്റ്‌ഫോം റൂളാണ് (ഡയറക്ട് ബൂട്ട് / ഫയൽ-അടിസ്ഥാന എൻക്രിപ്ഷൻ), ഒരു ട്രെയ്‌സ്‌ലെറ്റ് പരിമിതിയല്ല, ഇത് എല്ലാ SDK ലൊക്കേഷനും ബാധകമാണ്.

ഒരു തണുത്ത ബൂട്ടിന് ശേഷം ഉപകരണം ഡയറക്ട് ബൂട്ട് മോഡിലാണ്, മിക്ക ആപ്പ് ഡാറ്റയും ഇപ്പോഴും എൻക്രിപ്റ്റ് ചെയ്തിരിക്കുന്നു. ഉപയോക്താവ് ആദ്യമായി ഉപകരണം അൺലോക്ക് ചെയ്‌തതിനുശേഷം ** (പിൻ / പാറ്റേൺ / പാസ്‌വേഡ് / ബയോമെട്രിക്) Tracelet-ൻ്റെ ബൂട്ട് റിസീവർ കേൾക്കുന്ന BOOT_COMPLETED പ്രക്ഷേപണം മാത്രമേ Android നൽകൂ. അതുവരെ, Tracelet-ൻ്റെ കോൺഫിഗറേഷൻ, സ്റ്റേറ്റ്, ലൊക്കേഷൻ ഡാറ്റാബേസ് എന്നിവ സൂക്ഷിക്കുന്ന ക്രെഡൻഷ്യൽ-എൻക്രിപ്റ്റഡ് സ്റ്റോറേജ് ആക്സസ് ചെയ്യാൻ കഴിയില്ല - വായിക്കാനോ എഴുതാനോ ഒന്നുമില്ല.

അതിനാൽ ഒരു റീബൂട്ടിന് ശേഷമുള്ള ക്രമം ഇതാണ്:

ഉപകരണം ബൂട്ട് ചെയ്യുന്നു → ട്രേസ്‌ലെറ്റ് നിഷ്‌ക്രിയമാണ്.
ഉപയോക്താവ് ഒരിക്കൽ അൺലോക്ക് ചെയ്യുന്നു → BOOT_COMPLETED fires → Tracelet ട്രാക്കിംഗും സമന്വയവും പുനരാരംഭിക്കുന്നു.

ആദ്യം മാത്രം പ്രധാനമാണ്. അതിനുശേഷം സ്‌ക്രീൻ വീണ്ടും ലോക്കുചെയ്യാനാകും (ഫോൺ പോക്കറ്റിൽ, സ്‌ക്രീൻ ഓഫ്) കൂടാതെ ട്രാക്കിംഗ്/സമന്വയം സാധാരണ രീതിയിൽ തുടരുക.

ബൂട്ട് റെസ്യൂമെയ്ക്കുള്ള ആവശ്യകതകൾ: startOnBoot: true, stopOnTerminate: false, പശ്ചാത്തല-ലൊക്കേഷൻ (“എല്ലായ്പ്പോഴും”) അനുമതി നൽകി. Android 14+-ൽ, ബൂട്ടിൽ നിന്ന് ലൊക്കേഷൻ ഫോർഗ്രൗണ്ട് സേവനം ആരംഭിക്കുന്നത് OS അധികമായി വിലക്കുന്നു, അതിനാൽ ആപ്പ് അടുത്തതായി തുറക്കുന്നത് വരെ Tracelet വീണ്ടും WorkManager/alarm ട്രാക്കിംഗിലേക്ക് (സ്ഥിരമായ അറിയിപ്പ് ഇല്ല) വരുന്നു.

iOS റീബൂട്ടിൽ യാന്ത്രികമായി ആരംഭിക്കാൻ കഴിയില്ല - ഉപയോക്താവ് ആപ്പ് തുറക്കുന്നത് വരെയോ അല്ലെങ്കിൽ കാര്യമായ ലൊക്കേഷൻ-മാറ്റം അത് വീണ്ടും സമാരംഭിക്കുന്നതുവരെയോ ആപ്പുകൾക്ക് ബൂട്ടിൽ പ്രവർത്തിക്കാനും ലോഞ്ച് ചെയ്യപ്പെടാതിരിക്കാനും കഴിയില്ല, ഇത് ആദ്യത്തെ റീബൂട്ട് അൺലോക്കിന് ശേഷം മാത്രമേ സംഭവിക്കൂ.

ആദ്യ അൺലോക്കിന് മുമ്പ് ട്രാക്ക് ചെയ്യാൻ കഴിയുമോ?

സ്വതവേ അല്ല. അൺലോക്ക് ചെയ്യുന്നതിന് മുമ്പ് ലൊക്കേഷനുകൾ ക്യാപ്‌ചർ ചെയ്യുന്നതിന് Android ഡയറക്ട് ബൂട്ട് ആവശ്യമാണ്, അതായത് Tracelet-ന് ആവശ്യമായ ഡാറ്റ ഡിവൈസ്-എൻക്രിപ്റ്റഡ് സ്റ്റോറേജിലേക്ക് നീക്കുന്നു — ഉപയോക്താവിന് പ്രാമാണീകരിക്കുന്നതിന് മുമ്പ് വായിക്കാൻ കഴിയും, ക്രെഡൻഷ്യൽ-എൻക്രിപ്റ്റഡ് (ഓപ്ഷണലായി encryptDatabase- സംരക്ഷിത) സ്റ്റോറേജ് ട്രേസ്‌ലെറ്റിനേക്കാൾ ദുർബലമായ അറ്റ്-റെസ്റ്റ് ഗ്യാരണ്ടി. നിങ്ങളുടെ ഡാറ്റ പൂർണ്ണമായി പരിരക്ഷിക്കുന്നതിന്, ബോക്‌സിന് പുറത്ത് ഡയറക്ട് ബൂട്ട് പ്രവർത്തനക്ഷമമാക്കാൻ Tracelet അല്ല ചെയ്യുന്നു. നിങ്ങളുടെ ഉപയോഗത്തിന് പ്രീ-അൺലോക്ക് ട്രാക്കിംഗ് ഒരു ഹാർഡ് ആവശ്യകതയാണെങ്കിൽ, അത് ഒരു വിപുലമായ, ആപ്പ്-ലെവൽ ഓപ്റ്റ്-ഇൻ ആയി പ്രവർത്തനക്ഷമമാക്കാം - അതിനെ ആശ്രയിക്കുന്നതിന് മുമ്പ് ബന്ധപ്പെടുക.

ജിയോഫെൻസിംഗ്

ഞാൻ മോക്ക് / സിമുലേറ്റഡ് ലൊക്കേഷനുകൾ ഉപയോഗിച്ച് പരീക്ഷിക്കുമ്പോൾ ജിയോഫെൻസ് ട്രാൻസിഷനുകൾ പ്രവർത്തിക്കില്ല (ഇത് 1.x-ൽ പ്രവർത്തിച്ചു)

മോക്ക് ലൊക്കേഷനുകൾ ഇപ്പോഴും പ്രവർത്തിക്കുന്നു - എന്നാൽ ഉയർന്ന കൃത്യതയുള്ള ജിയോഫെൻസ് മോഡിൽ, ജിയോഫെൻസ് വിലയിരുത്തുന്നതിന് മുമ്പ് നിങ്ങളുടെ പരിഹസിച്ച പരിഹാരങ്ങൾ ഫിൽട്ടർ ചെയ്യപ്പെടുന്നു. geofenceModeHighAccuracy: true ഉപയോഗിച്ച്, തുടർച്ചയായ-GPS സ്ട്രീമിൽ നിന്ന് ഇൻ-ആപ്പിൽ സംക്രമണങ്ങൾ കണക്കാക്കുന്നു, കൂടാതെ ഫിൽട്ടർ ഫിൽട്ടർ ലൊക്കേഷൻ പാസ് പരിഹരിക്കുന്നതിൽ മാത്രം പ്രവർത്തിക്കുന്നു. റൂട്ട്-സിമുലേഷൻ ടൂളുകൾ സാധാരണയായി പോയിൻ്റുകൾക്കിടയിൽ “ടെലിപോർട്ട്” ചെയ്യുന്നു, ആ ജമ്പുകൾ നിരസിക്കപ്പെടും:

maxImpliedSpeed - ദൂരെയുള്ള രണ്ട് സാമ്പിളുകൾക്കിടയിലുള്ള അസംഭവ്യമായ വേഗത ഒരു ഔട്ട്‌ലിയർ ആയി കണക്കാക്കുകയും ഒഴിവാക്കുകയും ചെയ്യുന്നു.
useKalmanFilter: true - സുഗമമായ വഴക്കുകൾ പെട്ടെന്നുള്ള, നോൺ-ഫിസിക്കൽ മോക്ക് ജമ്പുകൾ.
trackingAccuracyThreshold — ചില മോക്ക് പ്രൊവൈഡർമാർ accuracy = 0 അല്ലെങ്കിൽ ത്രെഷോൾഡ് പരാജയപ്പെടുന്ന ഒരു അയഥാർത്ഥ മൂല്യം റിപ്പോർട്ട് ചെയ്യുന്നു.

രജിസ്ട്രേഷനിൽ geofenceInitialTriggerEntry: true ഒരു ENTER പുറപ്പെടുവിക്കുന്നതിനാൽ നിങ്ങളുടെ നിലവിലെ ലൊക്കേഷനിൽ സ്ഥാപിച്ചിരിക്കുന്ന ഒരു ജിയോഫെൻസ് ഇപ്പോഴും തീപിടിക്കുന്നു (ചലനമൊന്നും ആവശ്യമില്ല) - അതിനാൽ അത് ഒരിക്കലും ഫിൽട്ടറിലൂടെ കടന്നുപോകുന്നില്ല.

ഉയർന്ന കൃത്യത മോഡിൽ മോക്ക് ടെസ്റ്റിംഗിനായി, ഫിൽട്ടറുകൾ വിശ്രമിക്കുക:


geo: tl.GeoConfig(
  distanceFilter: 0,
  disableElasticity: true,
  filter: tl.LocationFilter(
    rejectMockLocations: false,
    useKalmanFilter: false,        // disable smoothing
    maxImpliedSpeed: 0,            // 0 disables the implied-speed reject
    trackingAccuracyThreshold: 0,  // accept regardless of reported accuracy
  ),
),

കൂടാതെ ഡെവലപ്പർ ഓപ്‌ഷനുകൾ → മോക്ക് ലൊക്കേഷൻ ആപ്പ് തിരഞ്ഞെടുക്കുക എന്നതിന് കീഴിൽ നിങ്ങളുടെ മോക്ക് ആപ്പ് തിരഞ്ഞെടുക്കുക, കൂടാതെ ചെറിയ, റിയലിസ്റ്റിക് ഘട്ടങ്ങളിലൂടെ സിമുലേറ്റഡ് റൂട്ട് മുന്നോട്ട് കൊണ്ടുപോകുക.

ഏറ്റവും ലളിതമായ പാത സ്റ്റാൻഡേർഡ് ജിയോഫെൻസ് മോഡിൽ (geofenceModeHighAccuracy: false) പരീക്ഷിക്കുക, അത് OS ജിയോഫെൻസിംഗ് സേവനത്തിലേക്ക് നിയോഗിക്കുന്നു. OS സംയോജിപ്പിച്ച ദാതാവിനെതിരെ വിലയിരുത്തുകയും സിസ്റ്റം മോക്ക്-ലൊക്കേഷൻ ആപ്പിനെ ബഹുമാനിക്കുകയും ചെയ്യുന്നു SDK ഫിൽട്ടറുകൾ ഇല്ലാതെ ≥ ~100 m** റേഡിയസ് അവിടെ ഉപയോഗിക്കുക, കാരണം OS ഒരു പ്രായോഗിക മിനിമം നടപ്പിലാക്കുന്നതിനാൽ ചെറിയ/എക്സിറ്റ് സംക്രമണങ്ങൾ അതിന് താഴെ വിശ്വസനീയമല്ല.

debug: true, logLevel: verbose എന്നിവയ്‌ക്കൊപ്പം, Location filtered by Rust processor: <reason>-നുള്ള ലോഗുകൾ കാണുക - പരിഹസിച്ച ഓരോ ഫിക്സും ഏത് ഫിൽട്ടറാണ് ഉപേക്ഷിച്ചതെന്ന് ഇത് നിങ്ങളോട് പറയുന്നു.

എന്തുകൊണ്ടാണ് ഞാൻ ഒരേ ജിയോഫെൻസിനായി, പ്രത്യേകിച്ച് ആക്രമണാത്മക-OEM Android ഫോണുകളിൽ (Xiaomi, Vivo, Oppo…) ആവർത്തിച്ച് ENTER/EXIT കാണുന്നത്?

ട്രേസ്‌ലെറ്റ് ഇതിനകം തന്നെ മരണ പ്രക്രിയയെ അതിജീവിക്കുന്ന ഒരു റെസ്യൂം-സേഫ് “അകത്ത് അറിയാവുന്ന” അവസ്ഥ തുടരുന്നു, അതിനാൽ ഒരു OEM നിങ്ങളുടെ ആപ്പ് കൊല്ലുകയും വീണ്ടും സമാരംഭിക്കുകയും ചെയ്യുന്നത് സോൺ വിട്ടുപോകാത്ത ഒരു ഉപകരണത്തിനായി ENTER വീണ്ടും ഫയർ ചെയ്യില്ല.

ഒരു സോൺ “പുതുക്കാൻ” എല്ലാ ലോഞ്ച് ചെയ്യുമ്പോഴും addGeofence()-ന് തൊട്ടുമുമ്പ് removeGeofences() എന്ന് വിളിക്കുന്ന ഹോസ്റ്റ് ആപ്പ് ആണ് സാധാരണ കാരണം:


// Don't do this on every app start:
await tl.Tracelet.removeGeofences();
await tl.Tracelet.addGeofence(tl.Geofence(identifier: 'OFFICE', latitude: lat, longitude: lng, radius: radius));

removeGeofences() മനഃപൂർവ്വം അത് അവസ്ഥത്തിനകത്ത് നിലനിന്നിരുന്നു - വേലി യഥാർത്ഥമായി ഇല്ലാതായതിനാൽ അത് ചെയ്യണം. addGeofence() ഇതിനകം തന്നെ ** ഐഡൻ്റിഫയർ മുഖേന അപ്‌സേർട്ട് ചെയ്യുന്നതിനാൽ, പുതിയ കോർഡിനേറ്റുകൾ ഉപയോഗിച്ച് അതിനെ വീണ്ടും വിളിക്കുന്നത് നിലവിലുള്ള വേലി അപ്‌ഡേറ്റ് ചെയ്യുന്നു:


// Do this instead — updates OFFICE if it exists, creates it if not:
await tl.Tracelet.addGeofence(tl.Geofence(identifier: 'OFFICE', latitude: lat, longitude: lng, radius: radius));

ഒരു വേലി യഥാർത്ഥത്തിൽ ഇല്ലാതാക്കപ്പെടുമ്പോൾ മാത്രം removeGeofence() / removeGeofences() എന്ന് വിളിക്കുക, അതേ ഐഡൻ്റിഫയർ ഉപയോഗിച്ച് ഇപ്പോഴും നിലനിൽക്കുന്ന ഒന്ന് പുതുക്കരുത്. അപൂർവ്വമായി കൊല്ലപ്പെടുന്ന ഒരു ഉപകരണത്തിൽ, നീക്കം-പിന്നീട്-ഇനിറ്റ് പാത്ത് തണുത്ത ആരംഭത്തിൽ ഒരിക്കൽ പ്രവർത്തിക്കുന്നു, അത് അദൃശ്യമാണ്. ഒരു ആക്രമണാത്മക OEM-ൽ, OS നിങ്ങളുടെ ആപ്പ് ആവർത്തിച്ച് കൊല്ലുകയും വീണ്ടും സമാരംഭിക്കുകയും ചെയ്യുമ്പോൾ മണിക്കൂറിൽ ഡസൻകണക്കിന് തവണ ഇത് വീണ്ടും പ്രവർത്തിപ്പിക്കാൻ കഴിയും, കൂടാതെ ഒരു യഥാർത്ഥ GPS ഫിക്സ് വരുന്നതിന് മുമ്പ് ഓരോ റണ്ണും അന്തർ അവസ്ഥത്തെ തുടച്ചുനീക്കുന്നു - ഓരോ തവണയും SDK-യുടെ ഇപ്പോൾ-ശൂന്യമായ വീക്ഷണകോണിൽ നിന്ന് പുതിയതും സാങ്കേതികമായി ശരിയായതുമായ ENTER ഉത്പാദിപ്പിക്കുന്നു.

ഡാറ്റ സുരക്ഷയും സ്വകാര്യതയും

വിശ്രമവേളയിൽ എൻ്റെ ലൊക്കേഷൻ ഡാറ്റ എൻക്രിപ്റ്റ് ചെയ്തിട്ടുണ്ടോ?

ഓപ്ഷണലായി, അതെ. ലൊക്കേഷനുകൾ ബഫർ ചെയ്യുന്ന പ്രാദേശിക SQLite ഡാറ്റാബേസ് എൻക്രിപ്റ്റ് ചെയ്യാൻ encryptDatabase: true സജ്ജമാക്കുക. Android-ൽ ഇത് SQLCipher (AES-256) ഉപയോഗിക്കുകയും നിങ്ങളുടെ ആപ്പിലേക്ക് SQLCipher ഡിപൻഡൻസി ചേർക്കാൻ ആവശ്യപ്പെടുകയും ചെയ്യുന്നു - ഇത് ഓപ്‌ഷണലായി സൂക്ഷിക്കുന്നു, അതിനാൽ ഡിഫോൾട്ട് ബിൽഡ് ചെറുതായിരിക്കും, കൂടാതെ encryptDatabase എന്ന് വിളിക്കുന്നത് വ്യക്തമായ പിശകിന് കാരണമാകുന്നു. iOS-ൽ എൻക്രിപ്റ്റ് ചെയ്ത സ്റ്റോർ നേറ്റീവ് ആയി കൈകാര്യം ചെയ്യുന്നു.

രഹസ്യാത്മകതയ്‌ക്ക് പകരം തെളിവുകൾ നശിപ്പിക്കുന്നതിന്, ഓഡിറ്റ് ട്രയൽ (audit.enabled) ഓരോ റെക്കോർഡും (ഉദാ. SHA-256) ഹാഷ്-ചെയിൻ ചെയ്യുന്നു, അതിനാൽ വസ്തുതയ്ക്ക് ശേഷം ചരിത്രം മാറ്റിയിട്ടില്ലെന്ന് നിങ്ങൾക്ക് തെളിയിക്കാനാകും. പ്രൈവസി സോണുകൾ സെൻസിറ്റീവ് ഏരിയകൾക്കുള്ളിൽ (ഉപയോക്താവിൻ്റെ വീട് പോലുള്ളവ) പരിഹരിക്കലുകൾ അടിച്ചമർത്താനോ തിരുത്താനോ നിങ്ങളെ അനുവദിക്കുന്നു.

Tracelet മോക്ക് / വ്യാജ GPS ലൊക്കേഷനുകൾ കണ്ടെത്തുമോ?

അതെ, LocationFilter-ൽ mockDetectionLevel വഴി:

disabled (സ്ഥിരസ്ഥിതി) — എല്ലാ ലൊക്കേഷനുകളും നിരുപാധികം അംഗീകരിച്ചു.
basic — പ്ലാറ്റ്‌ഫോമിൻ്റെ “ഈസ് മോക്ക്” ഫ്ലാഗ് വിശ്വസിക്കുന്നു.
heuristic — ഫ്ലാഗ് മറയ്ക്കുന്ന സ്പൂഫറുകളെ പിടിക്കാൻ പ്ലാറ്റ്ഫോം ഫ്ലാഗ് പ്ലസ് നേറ്റീവ് ഹ്യൂറിസ്റ്റിക്സും ഡാർട്ട് സൈഡ് ടൈംസ്റ്റാമ്പ് പരിശോധനയും.

heuristic-ൽ, ഓരോ Location-ഉം എന്തിനാണ് യഥാർത്ഥമോ വ്യാജമോ എന്ന് വിഭജിക്കപ്പെട്ടത് എന്ന് വ്യാഖ്യാനിച്ചിരിക്കുന്നു, അതിനാൽ നിങ്ങൾക്ക് നിങ്ങളുടെ സ്വന്തം ലോജിക്കിൽ മോക്ക് ഫിക്സുകൾ സ്വീകരിക്കാനും ഫ്ലാഗ് ചെയ്യാനും നിരസിക്കാനും കഴിയും.

flutter_background_geocation-ൽ നിന്ന് മൈഗ്രേറ്റ് ചെയ്യുന്നു

ഞാൻ `flutter_background_geolocation`-ൽ നിന്നാണ് വരുന്നത് — സ്വിച്ച് എത്ര ബുദ്ധിമുട്ടാണ്?

Tracelet-ൻ്റെ API മനഃപൂർവം flutter_background_geolocation-ന് അടുത്താണ്, അതിനാൽ മിക്ക ആപ്പുകളും കുറഞ്ഞ മാറ്റങ്ങളോടെ മാപ്പ് ചെയ്യുന്നു - ready/start/stop, ലൊക്കേഷൻ/മോഷൻ/ദാതാവിൻ്റെ ഇവൻ്റുകൾ, HTTP സമന്വയം എന്നിവയ്‌ക്കെല്ലാം നേരിട്ടുള്ള തുല്യതകളുണ്ട്. കോൺഫിഗറേഷൻ/ഇവൻ്റ് മാപ്പിംഗ് ടേബിളിനായി പൂർണ്ണമായ മൈഗ്രേഷൻ ഗൈഡ് കാണുക.