разобрать изменить и собрать

Месяцев 3 назад собрал приложение.никаких бд и ничего нет .чтото легкое .Проект сам утерян .теперь мне надо както сделать пару изменеий в проекте заменить текст и тд.Не знаю что делать ?можно ли как то декомпилоровать апк изменить данные и обратно компелировать ?
Очень нужна ваша помощ

Ответ

для проведения таких действий вам потребуется:
dex2jar Java Decompiler ApkTool
Далее выполнить по следующим шагам:
Качаем dex2jar и извлекаем в папку, например С:\Decompile . Качаем Java Decompiler (например JD-GUI) и извлекаем файлы для удобства в ту же папку, куда и dex2jar. Качаем apktool и apktool-install-windows-r04-brut1.tar.bz2 и извлекаем файлы уже в системную папку. По умолчанию C:\Windows. (Не забыть скачать второй архив) Берем нужный apk файл и кладем в папку с dex2jar и Java Decompiler Открываем Командную строку (Обработчик команд Windows) в вышеупомянутой папке (В папке по пустому месте при зажатой кнопке Shift нажимаем правую кнопку мыши и выбираем Обработчик команд Windows). Вводим команду dex2jar <ваш apk файл> и если все прошло хорошо, в той же папке появится файл <название вашего файла>.apk.dex2jar.jar Запускаем jd-gui и открываем полученный на предыдущем шаге файл. (На Windows 7 открывать с правами администратора и с совместимостью Windows XP SP3) Выбираем пункт меню File-Save All Sources и сохраняем. Извлекаем полученный zip архив. Помещаем полученную папку в папку src (надо предварительно создать).(Что бы получилась примерно такая структура С:\Decompile\<название вашего файла>\src\com\android) Опять же в командной строке вводим команду apktool d <название вашего файла>.apk <название вашего файла>, где <название вашего файла>.apk-имя пакета, <название вашего файла>-папка для декомпиляции.
Если все хорошо, тогда в указанной папке будут исходники в двух форматах (java и smali), ресурсы и файлы AndroidManifest.xml, apktool.yml
Таким образом будут получены исходники. Правда после декомпиляции в коде есть, можно сказать, ошибки,например вместо true и false стоят 1 и 0 соответственно.

Различие между context и this

В андроиде есть context-ссылка, а на самой джаве есть this-ссылка. Так вот в чем разница контекста от зиса и можноли пример с контекстом а то я запутался в нем. Благодарю.

Ответ

this и Context – это принципиально разные вещи.
this – это ключевое слово языка Java. this – это ссылка на самого себя. Ссылка на объект, для которого был вызван метод.
Context (в android) – это абстрактный класс, предоставляющий методы для доступа к т.н. глобальной информации (к ресурсам, классам, для управления активити, сервисами и так далее).
Непосредственными субклассами классами Context являются классы ContextWrapper и MockContext. В свою очередь, прямыми субклассами класса ContextWrapper, в том числе, являются классы Application и Service, а непрямым – класс Activity
Пример с Context
getActivity().runOnUiThread(new Runnable() { @Override public void run() { // some actions } });
Здесь, для запуска кода в UI-потоке используется объект класса Activity (который является (непрямым) наследником класса Context).
Еще один пример с Context
LinearLayoutManager layoutManager = new LinearLayoutManager(getActivity());
Здесь в конструктор класса LinearLayoutManager передается объект класса Activity. Такой вызов, возможен, например, из фрагмента.
Из самой активити можно напрямую вызвать:
LinearLayoutManager layoutManager = new LinearLayoutManager(this);
так как this в методах активити является как раз объектом класса Activity

C# - Создание WPF окна в dll

Можно ли создать dll с функцией (в каком-то классе), которая строит WPF окно.

Ответ

Конечно!
Вы точно так же можете из любой функции создать окно:
var window = new MyWindow(); window.Show();
Не забудьте подключить сборки PresesntationCore, PresentationFramework и WindowsBase, а в свежей версии ещё и System.Xaml. И вы можете точно так же определить класс с окном в DLL, как и в основном приложении, через XAML.
Если у вас не получается добавить XAML для окна, вам понадобится вручную отредактировать csproj, как указано здесь

Если вы не в UI-потоке, и у вас WPF-приложение, вам придётся перебросить выполнение туда. Например, так:
Application.Current.Dispatcher.InvokeAsync(() => { var window = new MyWindow(); window.Show(); });

Если у вас консольное приложение, всё немного сложнее, т. к. у вас нету UI-потока. Вам нужно его создать. Как это делать, написано здесь
Вот рабочий пример:
var thread = new Thread(() => { var window = new MyWindow(); window.Show(); Dispatcher.Run(); });
thread.SetApartmentState(ApartmentState.STA); thread.Start();

Возможно ли средствами javascript прочитать сокеты по ip/порту стороннего сервера?

Сейчас с помощью php получаю данные из разных сокетов по ip:port (с помощью фунуции fsockopen). Это делается для получения играющей в данный момент композиции на разных радиостанциях:
$open = fsockopen($radioip,$radioport,$errno,$errstr,'.5'); if ($open) { fputs($open,"GET /7.html HTTP/1.1
User-Agent:Mozilla

"); stream_set_timeout($open,'1'); $read = fread($open,255); }
В результате основной javascript на главной странице регулярно обращается к этому php на сервере. Хочется, чтобы всё это работало без лишних запросов к серверу, а средствами самого браузера. Возможно ли сделать подобную функцию на javascript - чтобы передавать ей ip и port а в результате получать необходимые данные?

Ответ

К сожалению, любые запросы браузером вне вашего "Origin" возможны только, если на той отвечающей стороне в заголовках ответов есть Access-Control-Allow-Origin с вашим origin. Это дело все закрыто для безопастности, т.к. если бы можно было с любого сайта вызывать AJAXом другой - очень много всего плохого можно было бы делать так.
Подробнее про кросс-доменный AJAX например вот тут
Websockets при этом вам в данном случае совершенно не помогут, т.к. это отдельный протокол обмена данными между сервером и клиентом. И причем последнее время браузеры все чаще форсируют wss (шифрованные вебсокеты), для которых помимо поддержки Websockets еще и SSL на этом поддерживающем сервере нужен. Так что вам особо без промежуточного php скрипта не обойтись.
Если вы задаетесь этим вопросом по причине большой нагрузки на ваш сервер - стоит задуматься облегчением этого всего дела чем-то типа тех же websockets. Только не сторонними серверами, а вашим собственным. Который будет например сам с какой-то определенной частотой обновлять свой кэш по удаленным серверам и с определенной частотой(или по факту изменения) присылать информацию клиентам. В websockets соединение держится и в нем возможен двухсторонний диалог между клиентом и сервером. Тем самым клиентам не нужно будет постоянно обращаться к какой-либо страничке, а они просто получат websocket message по факту его отправки. Такое можно реализовать например на Node.js или ASP.net. На PHP лично я не видел подобных штук.

Прямоугольник с закругленными углами (xml, shape)

Можно ли программно сделать прямоугольник, у которого закруглить все углы кроме одного? Знаю, как сделать прямоугольник со всеми закругленными углами, но можно ли как-то сделать что бы один угол был не закругленным?
Для всех закругленных углов использую:


А нужно прямоугольник, который бы выглядел вот так:

Ответ

Как спроектировать проект? DTO, Anemic, MVVM

Что имеем:
Проект представляет из себя WPF приложение, взаимодействующее с сайтом, локальной БД и отображающее данные в пользовательском интерфейсе.
Пример работы:
На сайте есть что-то вроде топиков, которые время от времени обновляются. Нужно "скачивать" последнее состояние этих топиков и писать в локальную базу, назовем это синхронизацией. После синхронизации мы можем осуществлять быстрый поиск по базе, делать различные пометки, добавлять в избранное и т.д., взаимодействуя через интерфейс пользователя.
Видение структуры:
Модель получается одна, что для базы, что для MVVM. Однако еще я хочу создать также слой API, который будет взаимодействовать с сайтом и возвращать экземпляры моделей. Но тогда и в API понадобится модель.
В итоге получается 2 слоя (или 3?) - API и БД (+ MVVM). Работают с одной моделью. Значит нужно использовать Anemic модель? Или лучше разделить модели, для каждого слоя сделать свою?
Теперь про логику взаимодействия с VM. Если пользователь захочет получить топики по критериям, VM должен запустить синхронизатор, дождаться завершения и только после этого делать запросы к базе. Правильно ли будет синхронизаторы (парсеры), которые через API будут получать топики и обновлять их в базе, выделить в отдельные классы или предоставить эту логику VM-мам?

Что получилось:
Слой API, взаимодействующий с сайтом Слой БД Синхронизаторы, связывающие API и БД VM-ы, взаимодействующие с БД и API через синхронизаторы Общая DTO Anemic модель для API, БД и MVVM.

Правильно ли использовать данные разделения и подход к проектированию в целом?

Ответ

Жуткий поток сознания, который сложно понять.
У вас по сути десктопное приложение клиент к какому то сайту, которое позволяет забирать данные с сайта, просматривать их оффлайн и добавлять какую-то мета-информацию. А значит вот вам мои фломастеры...
Я предпочитаю подход, где есть модели(сущности) и сервисы, которые что-то могут сделать с этими сущностями, то есть anemic.
Модели (сущности) Не стоит плодить dto без надобности. А значит модель(сущность) "топик" будет одной для бд и для клиента сайта и для вьюмоделей, пока не потребуется иначе.
Слой доступа к данным - от него зависит всё. Я предпочитаю рассматривать его как внешнее хранилище. А это значит, что есть подобие Repository/Storage, из которого можно достать данные или положить. Он должен принимать сущности на своем внешнем уровне и внутри себя хранить как ему вздумается. Например быть разделенным на 2 слоя - верхний слой работает с сущностями, а нижний с простыми типами.
Тут много вариантов реализаций и от него зависит будут ли модели anemic. Я не приветствую rich model, которая знает как себя хранить, но модель, вырожденная в dto - тоже плохо, поэтому у меня модели содержат и данные и некоторые методы, которые мешают сохраняться напрямую и инода вынуждают использовать dto (но на практике у меня от dto больше проблем, чем от чистого anemic)
Клиент к сайту - модуль-обертка. В простом случае это 1-2 класса, которые прячут внутри себя сетевые запросы и трансляцию данных их в сущности. Вводить собственные типы данных на границе модуля (и возможно писать дополнительный адаптер/маппинг) есть смысл только если этот модуль будет переиспользоваться в других проектах или очень хочется большей изоляции модулей или у нас ORM, который сильно мешает. Иначе нарушаем YAGNI
Вид (WPF+MVVM) - WPF отображает, а MVVM предоставляет данные для отображения и связывает вид с моделью. MVVM дает данные для отображения и бегает в модель за данными или с просьбой выполнить какую то работу, но сам не содержит логику приложения. Его дело связать вид и логику приложения. Хотя даже при этом вьюмодели получаются жирными, поэтому некоторые добавляют контроллеры (MVVMC) к вьюмоделям, которые и берут на себя общение с моделью.
Синхронизация - это сервис, который относится к модели (не путать с сущностями), а не к виду, поэтому существует не как часть вьюмоделей.
Так мы получили условно модули. Работает все это вместе так:
Пользователь нажимает кнопку "синхронизировать" WPF кнопка забиндена на команду вьюмодели и срабатывает эта команда вьюмодель прямо или косвенно обращается к сервису синхронизации и просит "синхронизируй". Сама вьюмодель ничего большего не делает Сервис синхронизации используя клиент к сайту получает данные в виде сущностей и передает их слою базы данных для хранения. вьюмодель или ждет окончания синхронизации или использует события. вьюмодель отображает данные (лезет за ними в бд например) Те же сущности используются для отображения, ну разве что оборачиваются вьюмоделями(хорошая привычка).
Остались еще дополнительные данные, которых нет на сайте - пометки, метка "избранное" и так далее. Их можно хранить отдельно от сущности "топик", а можно как часть этой сущности (клиент к сайту просто не затронет те поля, что не знает). Декомпозиция слишком спорный процесс - я вот не люблю много колонок в бд, но сохранение и вычитывание графа тоже писать лениво.
Введение DTO - только при необходимости. DTO или сущности конкретного модуля (или использование простых типов) позволяют добиться большей изоляции модуля...но YAGNI требует подумать "а оно нам надо?"
Старайтесь обозначить границы модулей, чтобы работать только с ними. При этом внутренности модуля скрыты. Даже если нужна какая то внутренняя часть, то постарайтесь обеспечить доступ через фасад (границу модуля)

Использование async/await в Python

Почитал про использование async/await в других языках программирования и не совсем понял, как и когда их используют. Для чего они вообще нужны? С помощью них можно улучшить уже существующий код? В каких случаях не стоит их использовать?
PEP 492 introduced support for native coroutines and async / await syntax to Python 3.5. A notable limitation of the Python 3.5 implementation is that it was not possible to use await and yield in the same function body. In Python 3.6 this restriction has been lifted, making it possible to define asynchronous generators:
async def ticker(delay, to): """Yield numbers from 0 to *to* every *delay* seconds.""" for i in range(to): yield i await asyncio.sleep(delay)
PEP 530 adds support for using async for in list, set, dict comprehensions and generator expressions:
result = [i async for i in aiter() if i % 2]
Additionally, await expressions are supported in all kinds of comprehensions:
result = [await fun() for fun in funcs if await condition()]

Ответ

Смотрите. Async/await нужен для того, чтобы не блокировать поток выполнения на время ожидания какого-нибудь асинхронного события. Конструкция Async/await превращает по сути процедуру в корутину (сопрограмму): она прекращает своё выполнение на время await, дожидается асинхронного события, и возобновляет работу.
В не-async-варианте ожидание получается блокирующим, или нужно вручную делать трюки: запускать операцию и подписываться на её окончание. Async делает код более простым, линейным.
Пример (на псевдокоде):
Async:
DownloadToFile(url): filename = GetFilename() content = await DownloadUrl(url) WriteToFile(filename, content) ReportSuccess()
Не-async:
DownloadToFile(url): filename = GetFilename() BeginDownloadUrl(url, onfinished: lambda content: StoreContent(content, filename))
StoreContent(content, filename) WriteToFile(filename, content) ReportSuccess()
Вы видите, что без async контекст выполнения (локальные переменные и т. п.) приходится передавать в «хвост» функции (continuation) вручную. Если async-вызовов много, аналогичный код без async быстро становится сложным.

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

Использование async/await имеет смысл там, где у вас есть ожидание, не связанное с нагрузкой на процессор. Например, ожидание прихода данных из интернета, или чтения файла с диска. В этом случае вы освобождаете поток физический выполнения для системы, но логическое выполнение продолжается (после возврата из await).