КОТ++
Прикладное программирование
Системное программирование
Программирование микроконтроллеров

Если вы дадите человеку программу, то займете его на один день. Если вы научите человека программировать, то займете его на всю жизнь. (с) Васим Латиф

Опубликовано
Комментарии 0

Не так давно передо мной стояла серьёзная задача парсинга данных с некоторых сайтов. Проблема была в том, что обычный HTTP запрос не поможет, т.к. нужно, чтобы на странице отработал javascript и построил данные на странице, чтобы мы потом их спарсили. С помощью обычного HTTP запроса возвращается почти пустая страница. Выход очевиден - делать запрос через браузер, ждать пока отработают скрипты на странице и передавать исходный код уже сформированной страницы парсеру. Долго я гулял по гуглу прежде чем найти рабочее решение поставленной проблемы. Поэтому хочу поделиться с вами тем, что в итоге у меня получилось. Ниже привожу фрагменты кода с ключевыми моментами.
webView.getSettings().setJavaScriptEnabled(true);
webView.addJavascriptInterface(new MyJavaScriptInterface(), "HTMLOUT");
//нужно, чтобы загружалась полная версия сайта, а не мобильная
webView.getSettings().setUserAgentString("Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0"); 
webView.setWebViewClient(new WebViewClient()    
{
    @Override
    public void onPageFinished(WebView view, String url)
    {
        webView.loadUrl("javascript:window.HTMLOUT.processHTML('<html>'+"
        + "document.getElementsByTagName('html')[0].innerHTML+'</html>');");
    }

    @Override
    public void onReceivedError(WebView view, int errorCode, String description, String failingUrl)
    {
        super.onReceivedError(view, errorCode, description, failingUrl);
    }

	@Override
    public boolean shouldOverrideUrlLoading(WebView view, String url)
    {
        view.loadUrl(url);
        return true;
    }
});

private class MyJavaScriptInterface
{
    @JavascriptInterface
    public void processHTML(String html)
    {
        onPostExecute(html); 
        webView.stopLoading();
    }
}

public void execute()
{
    webView.loadUrl(url + urlQuery);
}
Методы execute и onPostExecute названы так, чтобы с получившимся классом можно было работать также как и с AsyncTask. Логика кода выше такая: браузер сообщает нам, что закончил свои дела по загрузке в событии onPageFinished, но теперь нам надо забрать исходный код страницы из браузера. Для этого прикручиваем JavaScriptInterface также как в коде выше. На stackoverflow.com находились различные вариации реализации этой хитрости, но почти ни один пример не работал. В каких-то тайных уголках гугла удалось найти решение и реализовать его, вот теперь делюсь хитрым приёмом с вами)

Теги , , ,
Автор

Опубликовано
Комментарии 0

В очередной раз хочу поднять тему NIH (not invented here) синдрома в программировании. Многие люди в том числе и я склонны к тому, чтобы каждый элемент проекта был разработан с нуля и своими руками. Это чревато беспричинно большими затратами времени, а также собственная разработка чаще всего не проходит должного тестирования. В итоге получается проект на который было затрачено уйма времени, т.к. разработчики писали помимо основного кода ещё и собственные движки и библиотеки, а он ещё и глючит.

Но у синдрома неприятия чужой разработки есть и свои плюсы. Программист, который «болен» NIH синдромом в процессе написания велосипедов досконально начинает разбираться в том как что работает получше своих коллег. Но это не значит, что всегда нужно делать все с 0. Потому как лепить велосипеды – это не единственный способ узнать, как работает тот или иной движок и пр. К тому же давайте тогда и компьютер свой с 0 сделаем. Ведь тот компьютер, которым мы пользуемся это чужая разработка, придётся свой изобретать.

Каждый раз, когда в проекте встаёт выбор между написанием своей библиотеки/движка и выбором уже существующих решений, очевидный вариант это определить, что будет быстрее: написать свою либу или освоить чужую. Могут быть разные ситуации, может даже случиться так, что придётся исправлять ошибки в чужой библиотеке (если она опенсорс). Но это в случае, если вам важны ваши времязатраты. Если же вас интересует делать все самому, то лучше делать самому, только сильно не увлекайтесь. Это опасный путь, можно случайно начать разрабатывать свою ОС.

Теги ,
Автор

Опубликовано
Комментарии 0

Туки-Тук – это удобный сервис для поиска и предоставления доступного жилья в короткие сроки.

Функционал:
- регистрация;
- верификация аккаунта по email и телефону;
- создание объявления о сдаче жилья в аренду;
- поиск объявлений по различным параметрам;
- бронирование объявлений;
- возможность выбор наилучшего кандидата для снятия жилья;
- рейтинги и отзывы.

Ссылка на сайт: http://tuki-tuk.com
Ссылка google play: https://play.google.com/store/apps/details?id=com.varvar.tuki_tuk

Теги ,
Автор

Опубликовано
Комментарии 1

Используете много картинок в своём андроид приложении? И при этом бывает вылетает ошибка OutOfMemory связанная с показом картинок? В таком случае этот пост для вас.

Сам недавно столкнулся с такой проблемой, поэтому в этой статье могу предложить некоторое решение. В моём приложении картинки загружались с сервера и отображались сразу в большом количестве на экране смартфона. И когда хип переполнялся из-за большого количества картинок в памяти приложение падало, падение можно обойти, но картинки всё равно уже не отображаются там где надо. Самое очевидное решение это подгружать только те картинки, которые пользователь может просматривать в данный момент. Но определить какие из ImageView сейчас находятся в видимости пользователя, а какие нет тоже не простая задача. А ведь охото сделать простое и быстрое решение.

На stackoverflow.com предлагали ужимать картинки, а потом выводить на экран. В принципе неплохое решение, но чтоб отобразить сразу много картинок нужно применить 7/10 шакалов ко всем картинкам.

Также видел совет по увеличению хипа для приложения, прописать в манифесте:

android:largeHeap=«true»

Но это мне кажется нужно использовать только при острой необходимости, когда уже были предприняты все основные методы по оптимизации.

Остаётся заюзать какую-нибудь библиотеку для подгрузки изображений из инета. На слуху у меня две таких либы: Picasso и Android-Universal-Image-Loader. Мне по некоторым причинам больше приглянулась вторая либа. Её то и попробуем использовать. Подключим в свой проект и пропишем код инициализации. Мне наиболее оптимальным кажется такой вариант (некоторые параметры были найден уже не вспомню на каком форуме):

        Executor downloadExecutor = Executors.newFixedThreadPool(5);
        Executor cachedExecutor = Executors.newSingleThreadExecutor();

ActivityManager am = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE); int memClass = am.getMemoryClass(); final int memoryCacheSize = 1024 * 1024 * memClass / 8; options = new DisplayImageOptions.Builder() .showImageOnLoading(R.drawable.ic_stub_image) .bitmapConfig(Bitmap.Config.RGB_565) .imageScaleType(ImageScaleType.IN_SAMPLE_INT) .cacheInMemory(true) .cacheOnDisc(true) .build(); File cacheDir = StorageUtils.getCacheDirectory(this); ImageLoaderConfiguration config = new ImageLoaderConfiguration.Builder(getApplicationContext()) .taskExecutor(downloadExecutor) .taskExecutorForCachedImages(cachedExecutor) .memoryCache(new UsingFreqLimitedMemoryCache(memoryCacheSize)) // 2 Mb .diskCache(new LimitedAgeDiskCache(cacheDir, 52428800)) .imageDownloader(new BaseImageDownloader(this, 5 * 1000, 30 * 1000)) .defaultDisplayImageOptions(options) .build(); ImageLoader.getInstance().init(config);

Далее скачиваем и показываем картинку:

ImageLoader.getInstance().displayImage(imageUrl, imageView, MainActivity.options);

Но позже выясняется, что такой вариант особо не спасает. В логах у нас также будет OutOfMemory. А что если грузить сначала превьюшки для изображений (т.е. сжатые маленькие картинки), а если юзер просматривает картинку полностью, то в этот момент подгружать уже оригинал? Попробуем (код для подгрузки превьюхи):

ImageLoader.getInstance().displayImage(imageUrl, imageView, new ImageSize(80, 80));

Для подгрузки оригиналов воспользуйтесь кодом чуть выше. Проверяем, работает!

Данное решение не оптимизирует работу приложения так, как хотелось бы одержимому перфекционисту, но вполне побеждает OutOfMemory!

Теги , ,
Автор

Опубликовано
Комментарии 0

Всякий раз, когда упоминаю то, что отлично прогаю на AS3, в ответ слышу одно: «Ты чо, flash же умер давно!». И в качестве аргумента выступает одно и то же, что на флеше уже никто ничего не делает. От этого ловлю дикий facepalm. С чего вы это всё берёте?

Чтобы развеять миф о том, что на флеше ничего уже не делают и не сделать пишу эту статью.

Для начала рассмотрим flash в мире браузеров. Flash якобы заменили HTML5, и поэтому flash ушёл умирать. Но даже на данный момент HTML5 не догоняет флеш, а возможно не догонит его никогда. HTML5 это прежде всего язык гипертекстовой разметки. В 5-ой версии добавлены всякие штуки для удобной работы с мультимедиа. Безусловно HTML5 это очень хорошая штука и позволяет делать сайты со всякими интерактивными плюхами без использования дополнительных плагинов. Но мне попадались куча сайтов, где этот хвалёный HTML5 давал жуткие тормоза, где Flash бы себе такого не позволил. С простыми анимациями HTML5 справляется, но уже даже на воспроизведении видео он даёт тормоза. Поэтому до сих пор на многих сайтах можно выбрать плеер для проигрывания видео (Flash или HTML5).

Но тут проблема не только у юзеров, а ещё и разработчиков. Флеш является некой виртуальной средой, в которой уже и запускается само флеш приложение. Разработчику без разницы где эта среда будет запущена, т.е. неважно под какой браузер разрабатывать приложение, оно везде будет работать одинаково. Поэтому для игр и для сложных интерактивных приложений Flash очень хороший вариант. Безумно сложно будет протестировать работу приложения во всех браузерах, ведь порой даже бывает неудобно проверять и подстраивать под все браузеры простую html вёрстку. Делая же на Flash, разработчику не надо заботиться о том, что очередной браузер чем-то может выделиться, ведь каждый браузер хочет как лучше, а получается как всегда. Ах да, ещё у HTML5 нет аппаратного ускорения, которое безусловно нужно для игр. Есть сырой WebGL, но связка HTML5 и WebGL не может соревноваться с флеш, флеш всё равно выиграет.

Поэтому на флеше до сих пор появляется множество браузерных игр. Поиграть в них можно, например, на одном из самых крупных флеш порталов http://www.kongregate.com/ И даже во ВК есть флеш игры.

Теперь перейдём на мобильные платформы. С помощью Adobe AIR можно, используя флеш, разрабатывать под мобильные платформы. А HTML5 такое умеет? Ладно, при чём тут HTML5, возьмём к примеру Unity. Unity тоже позволяет создавать мобильные игры и при чём очень хорошие. Но из-за того, что unity предназначен для любых игр, в него понавешано множество всяких штук, которые вряд ли будут использоваться при создании любой 2d игры. Использоваться не будут, а место в конечном файле игры занимать будут, а на мобильных платформах вес является важной вещью, отчасти потому, что игру будут скачивать через интернет, порой человеку, который сидит с мобилы не через вайфай очень важно, чтобы игра вместо 40мб весила всего 10мб. Ведь тогда сидя в пробке он поиграет в игру, а не будет ждать пока она скачается.

К тому же на флеше вы можете написать собственный движок, который будет заточен только для ваших игр. Но если вы школьник, то движок вам писать не надо и Unity для вас лучшее решение, т.к. порог входа для разработки игр на unity минимальный и знания программирования для создания очередной вырвиглазной игры почти не нужны.

Но Adobe AIR позволяет разрабатывать игры ещё и под десктопную виндовс. Обилие неплохих таких игр на стиме говорит само за себя.

На последок хочу рассмотреть такую фишку флеша как создание анимационных мульфильмов. Наличие от Adobe удобного флеш редактора позволяет создавать с нуля шедевры, или не шедевры, если у аниматора руки из жопы.

Тему флеша я обошёл вскользь, на подробности поскупился. В следующий раз как кто-то скажет вам брызгая слюнями, что флеш умер, то знайте – перед вами малограмотный рукожоп, который не знает что такое флеш и разобраться не хочет.

Возможно кто-то захочет прокомментировать в стиле: «У автора бобмит, он просто консерватор, любит старые технологии». Может так оно и есть, поэтому не тратьте своё время на банальные комменты.

Теги ,
Автор

| 1 | | 4 | 5 | 6 | 7 | 8 |