Nový messenger z pošty. Jak jsme udělali aplikaci rychle. Obtíže, které inspirovaly nápady

Dobrý den, Habr! Jmenuji se Yuri Buyanov, jsem vývojář TamTam messengeru. Dnes vám chci říct něco málo o tom, jak vznikl a jak funguje zevnitř. TamTam je nový posel Mail.Ru Group, která byla vyvinuta na základě aplikace OK Messages. V roce 2016 jsme v Odnoklassniki vytvořili samostatný messenger pro ty, kteří si často dopisují na sociálních sítích a pro které je to pohodlnější pomocí samostatné aplikace.

Experiment dopadl úspěšně, a tak jsme se na začátku roku rozhodli vyvinout „OK Messages“ jako samostatný messenger ze sociální sítě pod vlastní značku TamTam, ale již se zavedeným začínajícím publikem. Během prvních týdnů po spuštění se v TamTamu objevily desítky tisíc kanálů a publikum pokračovalo v komunikaci stejně aktivně jako v OK Messages. To bylo možné částečně díky rychlá práce aplikace a několik technické triky. Řeknu vám o nich více.

Obtíže, které inspirovaly nápady

Začněme potížemi: ​​byli to oni, kdo nám přinesl nápady, které byly následně implementovány do produktu a nakonec přeměněny na výhody aplikace. Jde především o rychlé a stabilní práci posel.

Počáteční publikum TamTamu je z různých částí světa, včetně těch s nepravidelným pokrytím mobilní síť(a někdy s úplná absence pevný internet). V některých zemích SNS mimo velká města je připojení 2G vlastně jediným oknem k internetu.

Důležité také bylo, že ne všem potenciálním uživatelům TamTam došly nákupy nový iPhone nebo HOT NOVINKA od Samsungu. Podle statistik je nejoblíbenějším zařízením pro iOS mezi našimi uživateli iPhone 5s a pro Android - levné Galaxy vydání 2014-2015. Zároveň má TamTam poměrně mladé publikum: 28 % denního publika tvoří lidé ve věku 27–34 let a více než polovina uživatelů (54 %) je mladší 35 let.

Jednou z prioritních oblastí při vývoji messengeru pro nás proto od samého počátku byla optimalizace aplikace z hlediska rychlost, takže vytváření sítí. Zkrátka bylo nutné, aby aplikace fungovala bez povšimnutí uživatelů na jakékoli úrovni připojení. A s každým růstem publika také. TamTam vykazuje v prvních měsících dobrá čísla: počet instalací se již blíží 3 milionům a počet kanálů je již více než 50 000.

Jak jsme udělali aplikaci rychle

Výkon z uživatelského hlediska je především rychlost spouštění. Čas, který uplyne, než se zobrazí nový obsah (například při otevření chatu s novou zprávou prostřednictvím oznámení push). Všeobecně plynulý chod – zejména rolování. V týmu iOS se snažíme testovat a měřit výkon na iPhone 5 a iPhone 4S. Tým Android má přihlášení pro Galaxy S3 a Megafon za 1000 rublů. Ve výsledku tak na výkonnějších zařízeních aplikace prostě letí.

V každé testovací sestavení Můžete povolit počítadlo snímků za sekundu a doba trvání operací v úzkých hrdlech se zaznamenává do systému protokolů a statistik.

Tento graf například ukazuje čas od okamžiku spuštění aplikace při otevření pushem, dokud ji uživatel neuvidí konkrétní zprávu na obrazovce. Dva poklesy v grafu odpovídají zahrnutí obsahu push pro polovinu a všechny uživatele.

I přes množství nástrojů a metrik zůstávají hlavním nástrojem pro hodnocení výkonu aplikace subjektivní pocity. Nikdo nemůže přesně říci, jaké zpoždění v milisekundách je přijatelné při otevření obrazovky se zprávou, ale téměř každý může říci, zda má pocit, že aplikace „koktá“.

Jak optimalizujeme? Nejprve si z hlavního vlákna vezmeme vše, co umíme: práci s databází (o tom více níže), práci se sítí, serializaci a deserializaci dat, zpracování obrazu a dokonce i výpočty související s rozložením textu.

Když spustíme aplikaci nebo otevřeme obrazovku chatu, provádění náročných operací na pozadí nezabrání viditelnému zpoždění. Některé operace, jako je rozložení bublin, je tedy stále potřeba optimalizovat v čase, zatímco jiné je lepší provést ihned po přijetí zprávy a uložit výsledek jejich provedení do databáze.

Při výběru řešení třetích stran a knihoven v úzkých hrdlech jsme se také snažili zohlednit rychlost a kompaktnost. Zejména proto jsme zvolili MessagePack (a konkrétně udělali benchmark různých implementací pro iOS), změnili knihovnu pro mapování dat do objektů z Mantle na YYModel a rozhodli jsme se pro lz4 jako algoritmus komprese provozu.

Navíc dosáhnout hladký provoz rozhraní Symptomaticky optimalizujeme vykreslování:

• vyhýbáme se vykreslování mimo obrazovku, které zatěžuje procesor;
• změnit velikost obrázků předem na pozadí namísto použití standardního UIViewContentMode pracujícího v hlavním vláknu;
• dělat naše hierarchie uživatelského rozhraní „ploché“ a jednodušší;
• Ukládáme do mezipaměti ty objekty a data, jejichž vytvoření je příliš nákladné. Od výšky textových buněk po YYTextLayout (objekt, který ukládá informace o zobrazení textu v knihovně YYText), NSAttributedStrings a dokonce i samotné UIViews.

Všechny seznamy jsou rozvrženy ručně bez automatického rozložení. I když také milujeme automatické rozložení a používáme deklarativní rozložení pomocí Masonry v kódu - ale pouze tam, kde je to vhodné.

Offline a práce se špatným internetem

Na práci se sítí Snažíme se minimalizovat provoz a latenci výběrem rychlého, kompaktního protokolu a agresivního ukládání do mezipaměti.

Ke komunikaci se serverem používáme pouze TCP sockety a binární protokol. To nám umožňuje přijímat aktualizace ze serveru v reálném čase a pracovat ve známějším režimu „žádost-odpověď“.

Samotné API, tedy sada příkazů nad nízkoúrovňovým protokolem, může být v budoucnu implementováno, pokud je to žádoucí, nad jiným transportem, například na webových soketech. Díky tomu všemu se nemusíme dotýkat logiky nejvyšší úrovně aplikace.

Samotné pakety se skládají z hlavičky pevné délky s informacemi o službě: kód příkazu, verze protokolu, délka užitečného zatížení. Odpovědi na požadavky mohou přicházet v různých pořadích a smíšené s příkazy serveru, takže záhlaví obsahuje pořadové číslo, které vám umožňuje přiřadit požadavek a odpověď.

Rozhodli jsme se vyzkoušet messagepack jako formát užitečného zatížení. Nevyžaduje přísnou definici schématu, je velmi kompaktní a má poměrně rychlé serializační knihovny pro mnoho platforem. V podstatě se jedná o efektivní binární verzi JSON. Abychom dále snížili spotřebu provozu, komprimujeme užitečné zatížení pomocí algoritmu lz4. Vybrali jsme si ho také pro jeho rychlost a nízkou zátěž CPU a baterie.

Jedním z hlavních způsobů, jak zajistit normální práce aplikace v podmínkách špatná síť - maximální podpora offline režimu. Aplikace by měla ukládat do mezipaměti co nejvíce dat, věnovat méně času a provozu synchronizaci a měla by být schopna odložit odesílání příkazů, dokud nebude k dispozici připojení. Navíc se připojení může vrátit i při příštím spuštění aplikace, tj. všechny nevyřízené úlohy odesílání musí být možné uložit do databáze.

Po připojení je klient autentizován a zároveň vyžaduje kritická data: nastavení, seznam kontaktů a chaty s nejnovějšími zprávami. Časové razítko uložíme nejnovější aktualizace(PROTI serverový systém odpočítávání) a předejte jej v žádosti, abyste získali zpět pouze to, co se skutečně změnilo. Jakmile je spojení navázáno, můžeme přijímat aktualizace v reálném čase: například nové zprávy nebo změny kontaktních údajů.

S historií chatových zpráv je vše trochu složitější. Nemá smysl stahovat celou historii všech chatů předem, ale to, co jsme jednou obdrželi, ukládáme do mezipaměti a snažíme se o to znovu nevyžadovat. Pokud se podíváme na to, které části historie chatu jsou uloženy v mezipaměti, můžeme vidět, že v historii jsou „mezery“. Například při aktualizaci seznamu chatů po přihlášení jsme viděli, že se změnila poslední zpráva v chatu. Zároveň máme v databázi sekci (nebo několik sekcí) historie chatu, uloženou v mezipaměti předchozí relace. Také nevíme, kolik zpráv je mezi nimi na serveru poslední zpráva v chatu a předchozí zprávě uložené v mezipaměti, a to přidává své vlastní potíže.

Proto kromě samotných zpráv uchováváme metadata o souvislých částech historie – kouscích, které jsme uložili do mezipaměti. Při posouvání chatu používáme tyto informace: pomáhají nám určit, zda se má načíst další stránka z databáze nebo odeslat požadavek na server. Nebo možná udělat obojí. Když jsou ze serveru přijaty nové sekce historie, tyto bloky změní velikost a vzájemně se sloučí (pokud klient chápe, že nově přijatá sekce historie spojuje dva samostatné bloky existující v databázi).

Protože mnoho operací lze provádět offline, vyvinuli jsme mechanismus pro ukládání úloh. Může spouštět úlohy, čekat na jejich dokončení, ukládat jejich stav do databáze nebo je načítat a spouštět při spuštění aplikace.

Úkoly mohou být uloženy v databázi; Vzhledem k tomu, že závislosti na jiných úlohách a na stavu aplikace mohou být poměrně složité, je jejich sledování implementováno i v samotných úlohách. Například úkol odeslat zprávu s fotografií musí zajistit, aby byla fotografie zpracována, nahrána do CDN (za to jsou zodpovědné samostatné úkoly), čekat (v případě potřeby) síťové připojení a teprve poté se přímo pokuste odeslat samotnou zprávu.

Dva triky pro hladký chod aplikace

Řeknu vám něco o několika tricích, které jsme použili, abychom obešli systémová omezení, která nám bránila vytvořit přátelské a hladké rozhraní. Použití aplikace pro iOS jako příklad.

Jedním z problémů během vývoje bylo nekonečný svitek v chatu, tedy načítání historie zpráv bez povšimnutí uživatele při rolování chatu nahoru. V 99 % případů je uživatel na konci chatu a chce se posunout nahoru, aby si mohl přečíst staré zprávy. Zde se potýkáme se dvěma problémy.

Za prvé, neustálé narážení na začátek seznamu zpráv a čekání na načtení každých pár obrazovek je otravné. Tento problém nebylo příliš obtížné vyřešit: nečekáme, až se uživatel posune úplně nahoru a uvidí tam „zkroucení“, ale snažíme se předem požádat předchozí stránky historie při rolování: jak z místní mezipaměti, tak ze serveru. Pokud jsou zprávy v mezipaměti nebo na rychlé připojení uživatel prostě nebude mít čas posunout se úplně nahoru, než budeme moci zobrazit nový zásobník zpráv.

Druhý problém se ukázal být mnohem závažnější: po vložení takové stránky na začátek seznamu zpráv (vytvořených na základě UITableView) se posune contentOffset pro již načtenou oblast a rolování „skočí“. Můžeme samozřejmě vypočítat velikost vložené stránky a změnit contentOffset zpět, ale to vede k prudkému zastavení animace posouvání, což je nevzhledné a uživatele to odrazuje. Zkusili jsme to udělat různými způsoby, včetně věcí, jako je sledování contentSize tabulky pomocí KVO, ale vždy selhal: UITableView je prostě chronicky špatně vybaven pro přidávání prvků na začátek seznamu.

Nakonec se nám po řadě pokusů podařilo tento problém vyřešit pomocí jakéhosi „hacku“: otočíme seznam vzhůru nohama pomocí .transform a pak každou buňku otočíme opačným směrem. Uživatel si ničeho nevšimne, ale nyní se contentOffset počítá odspoda a načítání starých zpráv to nijak neovlivňuje.

Toto řešení má řadu úskalí, ale také se nám je podařilo obejít a neobtěžují nás. Nejprve musíte převést indexy převrácených buněk na indexy ve vašem datovém modelu a naopak. Pokud máte více než jeden oddíl, výpočty budou velmi složité, takže je nejlepší omezit se na jeden. To nám samozřejmě brání používat plovoucí záhlaví sekcí, která by se hodila například na obrazovce chatu pro zobrazení oddělovačů dnů v historii. Ale plovoucí děliče nakonec nebylo tak těžké udělat ručně.

Za druhé, ve vzácných případech mohou nastat potíže s výpočtem souřadnic uvnitř buněk, například při práci s gesty, ale všechny lze také vyřešit. Za třetí, při načítání dat směrem dolů se problém vrací, ale k načítání při rolování dolů dochází velmi zřídka, takže pro nás to není příliš velký problém. V tomto případě při posouvání nepředčítáme, ale počkáme, až se uživatel posune na úplný konec tabulky, poté ukážeme indikátor načítání, aktualizujeme tabulku a změníme contentOffset.

Druhou výzvou, na kterou jsme narazili, byly animované a asynchronní aktualizace seznamu. Pokud několik nezávislé aktualizace vyskytují téměř současně (například stránka s historií je načtena v horní části chatu a nová zpráva je doručena ve spodní části), pak se data použitá delegátem tableView mohou změnit, i když animace předchozí aktualizace neskončila .

To může způsobit, že UITableView vykreslí nesprávnou buňku nebo úplně selže: to je ještě pravděpodobnější, pokud používáte předchozí hack. Můžete samozřejmě použít metodu reloadData, která je v UITableView synchronní, ale to vede k blikání, zastavení rolování a dalším věcem, které uživatele dráždí.

Zejména pro takové případy jsme vytvořili samostatnou frontu pro sekvenční zpracování takových aktualizací. Všechny změny modelu a jejich zobrazení v uživatelském rozhraní se provádějí uvnitř bloků, které jsou zařazeny do fronty. V tomto případě může blok frontu uzamknout na začátku animace nebo jiné asynchronní operace a po dokončení ji odemknout. Veškerá práce s tabulkou tedy probíhá postupně a data se nemění, dokud není dokončena předchozí animace.

Perzistence

K cache dat v klientovi iOS používáme knihovnu YapDatabase.

YapDatabase je obchod Key-Value nad SQLite s velmi rozsáhlou sadou funkcí. Tato knihovna se mi zdá mnohem jednodušší a flexibilnější než CoreData. Zde můžete vybrat mechanismus pro serializaci objektů v databázi: ve výchozím nastavení je to NSCoding a stále používáme stejný MessagePack.

YapDatabase nevyžaduje dědění objektu z základní třída nebo implementace nějakého protokolu, nesváže objekty s kontextem. Čtení a zápis se provádí pomocí synchronních nebo asynchronních transakcí.

A s pomocí rozšiřujícího systému jsou k dispozici všechny stejné možnosti jako ve „skutečné“ databázi: libovolné SQL dotazy a indexování několika polí, fulltextové vyhledávání, přihlášení ke změnám (jako v NSFetchedResultsController), šifrování plug-inů, práce s CloudKit atd. Hello-world Nebudu zde uvádět příklady práce s databází, jsou na wiki na githubu.

Na můj vkus YapDatabase zlepšuje produktivitu a přehlednost kódu, ale některým kolegům se to moc nelíbí. A dá se jim rozumět: po dlouhé práci s CoreData vyžaduje přechod na YapDatabase opravdu trochu kroucení mozkem.

Navíc, kdy asynchronní práce s databází přes více připojení musíte dobře rozumět tomu, jak databáze zpracovává požadavky na paralelní čtení a zápis: prostřednictvím jednoho nebo různých připojení. A také nezapomeňte, že objekty jsou aktualizovány v databázi jako celku. Kopii, kterou jste si před časem přečetli a upravenou, nemůžete jen tak uložit. Musíte načíst objekt z databáze, změnit jej podle potřeby a zapsat zpět v jedné transakci. V opačném případě můžete omylem zapsat zastaralá data do databáze.

Práce s databází obecně velmi pohodlně zapadá do našeho reaktivního stylu kódování. Asynchronní vzory transakcí (čtení/zápis/úprava jednoho objektu) lze velmi snadno zabalit například do signálů ReactiveCocoa a integrovat práci s databází do jednoho řetězce s odesíláním a zpracováním síťových požadavků.

Architektura aplikace

O architektuře nebudu moc mluvit, ale jak se říká, nedovolí mi nezmínit její zákonitosti žánru. O MVVM je již spousta zpráv a článků (například klasický tutoriál ve verzi pro Objective-C a RAC: část 1, část 2 nebo o implementaci tohoto vzoru pro Swift).

Pod vrstvou ViewModels se nachází sada služeb, které implementují (a pokud možno zapouzdřují) obchodní logiku, logiku protokolu a ukládání do mezipaměti. Navigace v aplikaci se provádí pomocí tzv. routeru, tedy objektu, který zapouzdřuje kód nutný k otevření konkrétní obrazovky. Ve skutečnosti bylo v procesu několik routerů, protože router má tendenci stát se jakýmsi velmi tlustým Božím objektem. Proto, kde je to možné, se jej snažíme rozložit. Například samostatný router je zodpovědný za celý proces registrace/autentizace uživatele.

Ze zkušeností z předchozích projektů jsme věděli, že Dependency Injection výrazně zjednodušuje strukturu aplikace a výrazně usnadňuje změny v architektuře. Na úplném začátku jsme pro DI používali framework Typhoon, ale při optimalizaci doby spouštění aplikace jsme zjistili, že řešení závislostí trvalo neúměrně dlouho dlouho na začátku aplikace (jednotky sekund za slabá zařízení). Proto jsme přešli na manuální DI přes property-based injection. Neřekl bych, že existuje více kódu: úroveň služby v aplikaci je obvykle konfigurována v jedné třídě a celá konfigurace služby je snadno čitelná. Pro rozšíření sdílení a zpráv se samozřejmě služby konfigurují samostatně, protože v tomto případě je potřeba mnohem menší sada.

Soudržnost kódu tedy zpočátku nebyla příliš velká a dokonce i poté docela dlouho po zahájení vývoje se nám podařilo přesunout část kódu služeb a údržby samostatná knihovna(přesněji dokonce sadu knihoven), která implementuje většinu vnitřní logiky messengeru včetně práce s protokolem a cachováním a kterou lze zabudovat do jiných aplikací.

, IT společnosti

Společnost Mail.ru Group, jejíž aktiva zahrnují Agent a ICQ messenger, spouští nový produkt TamTam, hlásí Kommersant. Toto je aplikace pro zasílání zpráv, která integruje základnu 290 milionů uživatelů registrovaných v Odnoklassniki.

Nový messenger nebyl vytvořen od nuly. Její autoři kreativně přepracovali koncept podobné aplikace, OK Messages, spuštěné v červenci 2016. Podle Vladimira Kochetkova, autora a manažera projektu TamTam, to umožnilo vyrobit nový produkt levně a rychle. Vývoj TamTamu trval čtyři měsíce.

"OK Messages" byl vytvořen týmem vývojářů sociální síť Odnoklassniki (součást holdingu Mail.ru Group). Mobilní aplikaci OK Messages si v únoru 2017 nainstalovalo zhruba milion majitelů chytrých telefonů platforma Android a více než 300 tisíc majitelů mobilních telefonů Zařízení Apple. Nyní budou tito uživatelé moci nahradit messenger TamTam instalací speciální aktualizace z Mail.ru.

„TamTam je spuštěn s počátečním publikem, existuje možnost najít přátele mezi miliony uživatelů, a to je jeho hlavní výhoda. Nyní, kdy jsou možnosti mnoha instant messengerů podobné, není pro uživatele hlavní pouze jedna funkce, ale lidé, se kterými v aplikaci komunikujete,“ domnívá se Vladimir Kochetkov.

Služba vám umožní korespondovat v osobních zprávách i ve skupinových chatech, sdílet nálepky s GIF animací, posílat fotografie, video a audio nahrávky. Messenger umožňuje komunikovat nejen s přáteli, ale také s předplatiteli. Mail.ru Group tvrdí, že by aplikace měla fungovat stabilně i při slabém internetovém připojení. Je již k dispozici v App Store a Google Play.

TamTam bude integrován s dalšími firemními projekty. Jak úspěšný příklad taková integrace, cituje zdroj Kommersant Číňany Posel WeChat. Jeho publikum se blíží 1 miliardě lidí. WeChat je jednou z komerčně nejúspěšnějších platforem. S její pomocí v Číně se uživatelé mohou například objednat k lékaři, zaplatit účty a objednat zboží.

Mimochodem, WeChat má důstojným konkurentem– Japonská komunikační linka. Oba messengery byly spuštěny v Asii, kde mají velký podíl na trhu. Samozřejmě v Japonsku a Koreji, v domovských regionech Line, se messengeru podařilo získat velmi silnou pozici, a to i díky silné reklamě a obrovskému množství produktů se značkou Line Friends.

Budoucnost TamTamu bude záviset na tom, zda najde svou vlastní identitu, která jej odliší od ostatních messengerů. „Možná je správné opustit značku OK a vytvořit multiplatformní projekt, který lze propagovat jak prostřednictvím VK, tak například prostřednictvím pošty Mail.ru,“ říká senior analytička Sberbank CIB Svetlana Sukhanova.

Publikum Odnoklassniki a Viber se výrazně překrývají, a pokud TamTam osloví uživatele Odnoklassniki, může Viber ztratit asi 10–15 % svého publika, poznamenává Ilya Korolev, manažer portfolia Internet Initiatives Development Fund.

Vývoj třetího messengeru skupiny Mail.Ru může být ovlivněn novou legislativou. Poslanci Státní dumy včera představili návrh zákona, který zakazuje anonymitu uživatelů messengerů. Identifikaci uživatelů sítě musí provést telekomunikační operátor pomocí předplatitelské číslo, která je v identifikační smlouvě uzavřené organizátorem burzy rychlé zprávy s telekomunikačním operátorem.

Dne 24. května byl Státní dumě předložen návrh zákona o nutnosti zavést pokuty za odmítnutí splnit výše uvedená ustanovení. Pro občany je pokuta 3-5 tisíc rublů, pro úředníky - 30-50 tisíc rublů, právnické osoby- od 800 tisíc do 1 milionu rublů.

Každý člověk, který tvořil e-mail na serveru mail.ru může automaticky používat Mail.Ru Agent messenger, přesněji jeho webovou verzi nazvanou „Web Agent“. Pro práci s ním není nutná žádná instalace, protože webová verze tohoto snadno použitelného programu s uživatelsky přívětivé rozhraní k dispozici ihned po přihlášení ke svému e-mailu.

Funkční

K dispozici:

• funguje ve většině moderních prohlížečů;
• odesílání textových zpráv, animací popř multimediální soubory uživatelé ze seznamu kontaktů;
• současné otevření až čtyř dialogová okna;
• vytváření skupinových chatů;
• vyhledávat kontakty podle telefonního čísla, e-mailu nebo ICQ.

Výhody a nevýhody

Pomocí online verze Agenta můžete odesílat bezplatné zprávy. Chcete-li to provést, musíte v hlavním okně messengeru vybrat požadované tlačítko nebo vybrat kontakt ze seznamu a označit, co je třeba udělat.

Během chatování můžete svým partnerům posílat textové zprávy, multimediální obsah nebo vzrušující kreslené videa zabudované do messengeru.

Webová verze podporuje současné otevírání čtyř dialogových oken a komunikaci se čtyřmi lidmi samostatně. Je také možné vytvářet a komunikovat ve skupinových chatech.

Webová verze podporuje většina z možnosti dostupné prostřednictvím standardní klient. Umožňuje vám přidat do seznamu kontaktů osobu, se kterou jste si dopisovali prostřednictvím e-mailu. Zde také můžete najít osobu podle jména a příjmení, poštovní adresa nebo icq číslo.

Výhodou mail.ru Agent messenger je, že jej vývojáři úspěšně vydali, aby nahradil populární ICQ. Webová verze aplikace dokonale doplňuje program, umožňuje komunikovat s přáteli bez ohledu na umístění, možnost instalace programu atd. Vše, co potřebujete, je přístup k počítači s přístupem na internet, na kterém můžete svůj provoz spustit poštovní schránka. Poté má uživatel mnoho příležitostí ke komunikaci s přáteli a rodinou.

V hlavní verzi programu má uživatel přístup k mnoha cenným a užitečné funkce. Zde tedy můžete uskutečňovat audio nebo video hovory se všemi uživateli messengeru. Chcete-li to provést, musíte přejít do seznamu kontaktů, vybrat osobu, která vás zajímá, a vybrat typ hovoru: hlasový hovor nebo videohovor.

Pomocí programu může uživatel volat pravidelně telefonní čísla. Na ovládacím panelu vpravo je obrázek telefonního sluchátka. Musíte na něj kliknout, poté se otevře okno vytáčení. Pokud chce uživatel volat zdarma, musí vytočit číslo osoby, která používá messenger. V opačném případě budete muset za službu zaplatit. Chcete-li to provést, musíte dobít zůstatek prostřednictvím svého osobního účtu.

Chcete-li otevřít Osobní účet, musíte otevřít nabídku a přejít na „Nastavení“. Kromě možnosti dobít si účet zde můžete měnit nastavení hovorů, pracovat s tarify a provádět mnoho dalších funkcí.

Možnost uskutečňovat hlasové hovory nebo videohovory bohužel není k dispozici ve webové verzi programu mail.ru Agent messenger. Tato verze programu je implementována pro výměnu uživatelů textové zprávy a lze jej použít v případech, kdy není možné nainstalovat plnohodnotného klienta a používat jej. Může to být počítač nebo zařízení někoho jiného zastaralá verze OS.

Systémové požadavky

• OS: Windows 7, 8, 10

Jak nainstalovat Mail.Ru Agent

Chcete-li používat online verzi mail.ru Agenta, není nutné instalovat desktopovou verzi aplikace do vašeho počítače. Program funguje přes libovolný moderní prohlížeč, aktualizováno na nejnovější verzi- a mnoho dalších. Stačí zadat své uživatelské jméno a heslo do pošty Mail.ru, přihlásit se do své poštovní schránky a spustit Agenta kliknutím na panel v pravém dolním rohu.

Pro jiné systémy

Od představení nového messengeru TamTam od Mail.ru Group neuplynul ani týden a na internetu se již vedou vášnivé diskuse o jeho přednostech a perspektivách. Korespondent tiskové agentury AmurMedia Jevgenij Nikitenko v rámci rubriky DIGITAL zkoumá, jaká je nová aplikace, která nahradila „OK zprávy“.

Od samého začátku projektu vývojáři upozorňovali veřejnost, že TamTam je přehodnocením „OK zpráv“ s baldachýnem ve tvaru další funkce. Ne nadarmo je naznačený OK messenger jednoduše nahrazen TamTamem prostřednictvím obyčejné aktualizace. Pojďme se ale sami podívat, čím nás nový program potěší, protože, vidíte, je zajímavé, jak dokáže překvapit společnost, která již vlastní takové instant messengery jako ICQ a Mail.ru Agent, sociální sítě Odnoklassniki a VKontakte. unavené moderní publikum?

Abych byl upřímný, před instalací TamTamu jsme trochu váhali mobilní zařízení, protože si z předchozích zkušeností dokonale pamatovali, jak obtížné může být odstranit produkty skupiny Mail.ru osobní počítač, natož smartphone - nikdo nechtěl vrátit systém zpět do továrního nastavení. V důsledku toho bylo rozhodnuto nainstalovat program na smartphone s OS Android, zejména proto, že dříve bylo uvedeno, že „TamTam je zcela zdarma a neprokazuje reklamní sdělení“, a to dává naději, že doplňkové produkty nebudou zahrnuty.

No a začneme, aplikace je naštěstí dostupná pro Android i iOS. Stojí za zmínku, že za méně než týden od spuštění aplikace se s Play Market Už si ji stáhlo více než 1 milion lidí.

Mimochodem, pokud jde o účty: TamTam je integrován s Odnoklassniki, takže není třeba vytvářet nový „účet“. Zároveň si můžete snadno vytvořit účet v TamTam, aniž byste byli vázáni na sociální síť, ale jde o poměrně kontroverzní krok, protože tím „odříznete“ značnou část funkčnosti a připravíte se o tyto výhody. které se mohou stát pobídkou k výběru tento posel. Mimochodem, přihlásit se můžete i přes Google.

Samotné rozhraní TamTam nenabízí nic radikálně nového a nepředstírá, že jde o převratné nápady: po instalaci uvidíme přesně to, co jsme viděli v desítkách messengerů dříve a pravděpodobně i po letech mnoha dalších služeb. Mezi opravdu zajímavé rozdíly od stejného Viberu nebo WhatsAppu stojí za zmínku schopnost exportovat kontakty nejen z paměti samotného telefonu, ale také přímo ze seznamu „přátel“ v Odnoklassniki. Ale to bude samozřejmě teprve zajímavé aktivní uživatelé sociální síť - pro ostatní, jako je náš korespondent, který čas od času navštíví jeho stránku, schopnost „exportovat“ počasí to neumožňovala.

Messenger TamTam. Foto: Evgeny Nikitenko, kor. IA AmurMedia

Když už mluvíme o funkčnosti - TamTam umožňuje korespondovat v soukromých zprávách, vytvářet skupinové chaty, posílejte nálepky, gify, fotky a zvuk. Hovory nejsou ani video, ani zvuk, alespoň zapnuté v této fázi, nebude možné splnit. Což ovšem novince na pozadí stávajícího body nepřidá mobilní aplikace. Ale kanály, kterým uživatele učil jiný mladý Telegramový posel- myšlenka je potenciálně (zejména s přihlédnutím ke spojení TamTam-Odnoklassniki) docela slibná. O něco později si vysvětlíme proč.

Některé hvězdy také spustily kanály v den, kdy byl spuštěn messenger Ruský showbyznys, například Polina Gagarina, ke které se za tuto dobu stihlo přihlásit téměř devět set uživatelů.

Kanály TamTam. Foto: Evgeny Nikitenko, kor. IA AmurMedia

Vyhlídky kanálů jako takových v případě TamTam jsou odůvodněny především třísetmilionovým publikem Odnoklassniki, ale kolik uživatelů přejde na messenger, pokud není integrován do webové verze sociální sítě, zůstává v otázka. Korespondence mezi TamTam a Odnoklassniki je jedna věc, ale abyste mohli sledovat kanál, budete muset získat posla, a zde vyvstává otázka, zda je vhodné jej nainstalovat pouze kvůli přístupu ke kanálům.

Redakci zmátla i sada nálepek, které se mírně řečeno nápadně liší od onoho roztomilého seznamu z Odnoklassniki. Stačí porovnat:

Spolužáci

Sada samolepek v Odnoklassniki. Foto: Evgeny Nikitenko, kor. IA AmurMedia

TamTam

Sada samolepek v TamTam. Foto: Evgeny Nikitenko, kor. IA AmurMedia

Ale prozatím je lepší nechat nálepky bez komentářů, někomu se líbí kanonické, jiní budou pro novou, velmi unikátní možnost. V každém případě mají všechny fixy různé chutě a barvy, a tak vás, milí čtenáři, zveme, abyste sami rozhodli o svém postoji k oběma verzím.

Vrátíme-li se k přednostem messengeru, sami autoři uvádějí, že funguje i s špatný internet připojení a můžete posílat zprávy offline - zprávy budou doručeny příjemci, jakmile se objeví síť. Není jasné, zda má cenu na tento „úspěch“ vůbec upozorňovat, protože takovou „funkcí“ se mohou pochlubit i takoví „dědečkové“, jako je WhatsApp.

Na závěr poznamenáváme, že podle našeho názoru TamTam zjevně není zabijákem konkurenčních messengerů, ale pokud se rozhodnete propagovat společnost, může to být dobrá volba. TamTam byl koneckonců vytvořen na základě Odnoklassniki, a proto má každou šanci rychle přilákat významnou část jejich mnohamilionového publika, které nikdo nezakazuje „tahat“ na svůj kanál. To, jak využijete vznikající příležitosti, přitom záleží jen na vás – program je nový, má velmi určitou perspektivu, ale nejspíše ve specifickém rámci stávajícího publika. Pokud jde o použití programu přímo jako messenger, cesta vývoje je zde stále nejasná a jen čas ukáže, co z toho vzejde: zda TamTam zůstane specializovaným produktem nebo získá širokou popularitu.

Mimochodem, co si myslíte o novém messengeru od Mail.ru?