Last Friday afternoon, services using the Naver Map SDK experienced an issue where the map was not displayed.
For some services, an UIAlertViewController was shown in the format (Title: ErrorCode 510, Message: Endpoint connection timeout, Button: OK), while for others, no alert was displayed at all.
Initially, I suspected that Sentry or Alamofire was handling the network timeout issue automatically, so I reviewed the logs. However, no alert was being displayed.
Therefore, I assumed the issue originated from the Naver Map SDK and inquired about it on the Naver Map Forum.
The response suggested referring to the authentication failure section in the Naver Map documentation. Although the documentation is detailed, I had overlooked it because there was no specific mention of 510 or timeout errors.
Next time, instead of just assuming a network issue when encountering a timeout, I should also consider where the UIAlertController is being displayed.
In iOS, the CoreLocation framework is used to obtain the current location.
To determine the current location, multiple components such as Wi-Fi, Cellular, GPS, Bluetooth (iBeacon), magnetometer, and barometer are used to collect data.
Since CoreLocation has been available since iOS 2, it has undergone numerous updates.
Accessing location data requires requesting user permissions, which have changed over time. Permissions such as “Always Allow,” “Precise Location,” and “Allow Once” need to be reviewed based on the iOS version.
To simplify permission requests, UIKit and SwiftUI provide CoreLocationUI framework buttons.
Additionally, to improve asynchronous processing and background handling, CLLocationUpdate and CLMonitor were introduced in iOS 17 as wrappers for CLLocationManager.
To enhance location accuracy, we can refer to the accuracy value or specify the Activity Type based on movement type before requesting location access.
Here are some recommended blogs related to CoreLocation:
I visited the RIBs GitHub repository to study the framework. Since RIBs is a cross-platform architecture framework, it was previously available for both Android and iOS in a single repository, but it has now been separated into RIBs-iOS for each OS.
The tutorial is well-organized in the Wiki, so I was excited to follow it. However, due to incorrect project paths and version settings after the repository change, the build failed.
To resolve this, I forked the repository, fixed the paths and versioning issues, documented the build errors and solutions, and submitted a PR. Afterward, I proceeded with the tutorial on my branch.
One concern I had was the increasing number of files. However, RIBs provides a file template that automatically generates Router, Interactor, and Builder files. Additionally, it supports the creation of Viewless RIBs.
The most intriguing feature was the ability to create a Viewless RIB, allowing it to attach child RIBs dynamically. I plan to summarize my findings as I progress.
If you want to learn RIBs, I recommend the open-source project SimpleMemo-RIBs and Nosujin’s Fastcampus lecture.
minimumDate and maximumDate range in code causes a crash. from apple_store_scraper import AppStore
from pprint import pprint
import json
# Sample code for fetching app reviews
sample = AppStore(country="kr", app_name="KakaoTalk", app_id="362057947")
sample.review()
# Function to convert a datetime object to a string
def convert_datetime(obj):
if isinstance(obj, dict):
return {key: convert_datetime(value) for key, value in obj.items()}
elif isinstance(obj, list):
return [convert_datetime(item) for item in obj]
elif hasattr(obj, "isoformat"): # If it's a datetime object
return obj.isoformat()
else:
return obj
# Convert to a JSON-compatible format
reviews_data = {
"reviews": convert_datetime(sample.reviews),
"total_reviews": sample.reviews_count
}
# Save as a JSON file
with open("sample_reviews.json", "w", encoding="utf-8") as f:
json.dump(reviews_data, f, indent=4, ensure_ascii=False)
print("Review data has been saved as 'sample_reviews.json'.")