Возможно для того, чтобы приложение не перебирало все возможные схемы (приложения), чтобы понять какие установлены. Таким образом нарушалась конф. инф.
В случае языковых файлов становится невозможно быстро онлайн из интерфейса сайта изменить перевод или строчку на сайте. А по опыту — гораздо удобнее делать это через интерфейс, нежели копаться в файле.
Я тоже недавно делал локализацию на сайте. Остановился на таком способе:
Для локализации объектов:
И такая таблица для локализации самого сайта:
CREATE TABLE [dbo].[LocalizedViews](
[Id] [int] IDENTITY(1,1) NOT NULL,
[LanguageId] [char](2) NOT NULL,
[ViewPath] [varchar](50) NOT NULL,
[KeyName] [varchar](50) NOT NULL,
[Value] [text] NOT NULL,
[UpdatedAtUTC] [datetime] NOT NULL,
)
Кроме того что ответили ниже. Это не является законченным решением, а может поставляться как дополнительные фишки к основному приложению и программе лояльности для тех у кого есть BLE.
Вредить навряд ли получится. В своем приложении вы знаете идентификаторы ваших iBeacon устройств. Более того, при регистрации на отслеживание BLE устройств вы говорите системе какие идентификаторы смотреть. Таким образом чужие BLE метки не повредят вашей программе. Но подделка копий — возможно будет мешать. Здесь тоже есть варианты защиты.
Исхожу из своего опыта. Проделать все выше описанные операции знакомясь с платформой может быть довольно трудно. Геолокация в симуляторе приемлемая, со вторым дела не имел.
Разработку можно вести и на симуляторе. Он практически ничем не отличается от настоящих устройств на этапе попробовать систему, более того поддерживает разные платформы и версии операционной системы.
Хорошо. Тема MVVM для меня крайне болезнена. Я считаю, что использование MVVM в мобильных приложениях не всегда оправдано. Более того, даже в настольных приложениях готов подискутировать на эту тему. То, что показано выше нельзя называть MVVM. Это же только DataContext…
Для локализации объектов:
И такая таблица для локализации самого сайта:
Подробнее (для asp.net mvc)
(увидел ответ ниже)