Во время моей работы над Windows Phone 7, когда я писал свое первое приложение, я упустил из виду ряд вещей, которые я хотел бы оставить перед собой. Ни один из этих предметов не обязательно сложный или сложный, чтобы покрыть его, поэтому я подумал, что упомяну их здесь, чтобы избавить вас от неприятностей, и в то же время покажу вам способы преодоления каждого из них.
глобализация
На момент написания этой статьи устройства Windows Phone 7 были выпущены на 63 различных рынках , и, хотя иногда мы можем говорить об этом не слишком часто, большинство в мире не говорят по-английски.
Еще более актуально при написании приложений, которые обрабатывают данные третьих сторон, многие страны также не используют ту же самую дату или десятичную систему, как в США или Великобритании — и при анализе дат или чисел в локальном регионе это может легко сломать ваш код.
Если вы, например, находитесь во Франции или в большом процентном соотношении с Европой, вместо «Сто тысяч» пишется как «100 000,00», как в США, вместо «100 000,00».
Способ обойти это зависит от того, получаете ли вы данные в чужом регионе или отправляете данные в чужом регионе.
Ниже приведен пример кода, представляющего эту проблему (это не то, как вы должны использовать свое приложение, потому что лучше сохранять локальную культуру и вместо этого изменять способ анализа).
// Switch the current culture to French to simulate a French User Thread.CurrentThread.CurrentCulture = new CultureInfo("fr-FR"); Double Number = 123.00; // This will be "123,00" string Output = Number.ToString(); // This will be "123.00" string InvariantOutput = Number.ToString(CultureInfo.InvariantCult
Это означает, что если вы анализируете строки из США в целые или двойные числа (например, полученные из удаленных американских API, таких как Twitter или Google) и ваши пользователи находятся во Франции, ваше приложение сгенерирует исключение, так как формат числа выиграл не будут правильно распознаны — вам нужно либо указать культуру входящей строки, либо указать культуру как Инвариантная культура (по умолчанию США).
Возьмем следующий пример запуска на устройстве в США. Здесь мы возьмем набор культуры на французский (для моделирования французского пользователя) и затем успешно проанализируем числовую строку США / Великобритании.
Double Number = 123.00; // This will be "123.00" string Output = Number.ToString(); // Change the current culture to simulate a French User Thread.CurrentThread.CurrentCulture = new CultureInfo("fr-FR"); // This will throw an exception Double FrenchParsedNumber = Double.Parse(Output); // This will not throw an exception Double FrenchParsedNumberInvariant = Double.Parse(Output, CultureInfo.InvariantCulture);
Все приведенные выше примеры также однозначно применимы к разбору дат. В MSDN есть хорошая статья, показывающая, как это сделать с поставщиками формата DateTime .
Кроме того, вы можете протестировать свое приложение в различных условиях, изменив региональную культуру вашего эмулятора .
локализация
Хотя это не является проблемой для вашего приложения как такового , в то время как мы находимся на теме иностранных пользователей, стоит отметить, что очень скоро лишь крошечный процент рынка будет англоязычными странами, разделив ваш текстовый контент на международные файлы ресурсов сделают продажи на этих рынках намного более прибыльными — и любой, кто делал это раньше, скажет вам, что будет намного проще, если вы сделаете это с самого начала, даже если единственный языковой ресурс, которым вы располагаете, это английский для начала.
Действия по добавлению поддержки локального языка на страницы приложений Windows Phone 7 (основано на этой статье MSDN )
Создайте новый файл ресурсов в вашем приложении с именем Resources.resx
Добавьте новый файл для каждого дополнительного языка, который вы хотите поддерживать (например, названный Resources-FR.resx для французского, Resources-ES.resx для испанского).
В статье MSDN, указанной выше, показано, как создать класс LocalizedStrings , однако они не показывают, как использовать его для DataBinding, поэтому давайте решим это.
WPF / ASP.net и Silverlight обрабатывают привязку данных иначе, чем Winforms. Silverlight использует термин «Ресурс» для обозначения файлов, использующих действие «Сборка» «Содержимое», так как эти файлы упаковываются в файл .XAP, аналогично файлам с действием «Сборка» «Ресурс», встроенным в сборку .Dll.
Я обнаружил, что вместо использования синтаксиса XAML Text = «{Binding Path = resourceFile.resourceName, Source = {StaticResource Localizedresources}}» было проще выполнить следующие шаги:
- Откройте свою основную страницу XAML (обычно MainPage.xaml) в Visual Studio
- Откройте свойства для PhoneApplicationPage и установите DataContext равным Application.Resources -> LocalizedStrings. ПРИМЕЧАНИЕ: если вы уже используете объект DataContext, вам следует интегрировать класс LocalizedStrings в этот объект, чтобы он поддерживал локализацию.
- После того, как DataContext страницы был установлен, вы можете изменить привязку данных для любого элемента управления на странице, просто выбрав свойство (например: текст, проверил и т. Д.) И выбрав « Применить привязку данных…» и установив путь к LocalizedResources.BtnText. или любой другой ключ ресурса, к которому вы пытаетесь привязаться.
Помните: панель приложений не является элементом управления Silverlight и поэтому не может иметь ресурсы, связанные с ней таким же образом. Для этого вам нужно будет создать или обновить панель приложения во время выполнения.
Проблемы со входом в интернет-браузер Wi-Fi
Это еще одна проблема, которая на первый взгляд далека от 100%.
Ваши пользователи, вероятно, столкнутся с неверными данными при подключении к точкам беспроводного доступа, которые требуют входа в браузер (например, отель или библиотека). Обычно устройство должно запустить сеанс Internet Explorer, чтобы позаботиться об этом, но есть ряд ситуаций, когда это вам не поможет:
- Когда ваша фоновая задача запускается для обновления плитки, и пользователь еще не вошел в систему.
- Когда пользователь игнорирует страницу входа в браузер или прерывается во время ее использования (телефонный звонок и т. Д.) — это оставляет их в состоянии «онлайн», но не подключен к сети.
Довольно часто эти стены входа в браузер для Wi-Fi просто возвращают страницу входа для каждого запроса . Это означает, что ваше приложение будет думать, что оно говорит с Интернетом (или Twitter, или любым другим API, который вы используете), но вместо этого вернет неверные данные или код ответа 3XX перенаправления.
Что это значит для тебя?
Это означает, что при извлечении данных из внешнего интернет-источника убедитесь в следующем:
- Белый оборонительный код WebExceptions , такие как заявления Try уловов ( до тех пор , как вы только перехватывать исключения , которые вы ищете — не просто исключение).
- При доступе к источнику данных с известной или документированной схемой (такой как сторонний XML API) проверьте правильность возвращенных данных в файле схемы (в случае XML используйте XSD для проверки формата данных перед доступом к нему или десериализацией). Это гарантирует, что даже если данные будут возвращены, вы будете знать, что именно искали.
Всегда предполагайте, что данные, которые ваше приложение будет получать из Интернета, являются недействительными.
Сетевой интерфейс онлайн без интернета
Другая проблема, которая может повлиять на ваших пользователей и заставить их думать о вашем приложении как о плохих , связана с тем, что их устройства считают, что они подключены к сети, но не обязательно имеют доступ к Интернету. Это может произойти в областях с плохим покрытием или когда у их оператора есть проблемы с подключением к Интернету.
Обеспечение того, чтобы устройство имело сетевое подключение , не решит эту проблему, поскольку ваше приложение все еще будет зависать, если оно не сможет получить доступ к Интернету.
Есть два способа минимизировать эту проблему:
- Во время работы приложения каждые несколько минут загружайте небольшой текстовый файл, похожий на службу Microsoft NCSI, и используйте его для установки сетевого подключения (вы можете даже использовать URL-адрес MS, чтобы сэкономить время).
- Установите для тайм-аутов загрузок по сети вашего приложения значение, меньшее, чем значение по умолчанию, равное 100 секундам — стандартный пакет SDK для Windows Phone 7 HttpWebRequest не поддерживает свойство Timeout, поэтому ребята из WP7Contrib разработали хорошее решение для установки тайм-аутов в место. Я поставил на 40 секунд, так как это хороший компромисс между медленной скоростью сети и пользователями, которые ждут вечно — ваш пробег может меняться, так что проверяйте это, пока не найдете подходящую среду.
Резюме
В целом, есть несколько мелочей, которые могут добавить в ваше приложение блеска — часто ваши пользователи могут совершенно по-разному воспринимать ваше приложение в дикой природе, и чем ближе мы сможем охватить все эти вещи, тем лучше и счастливее. пользователи высоко оценивают ваше приложение, и вы получаете больше загрузок. В любом случае, вы смотрите на это, это хорошо.