Android業務元件化之URL Scheme使用
前言:
最近公司業務發展迅速,單一的專案工程不再適合公司發展需要,所以開始推進公司APP業務元件化,很榮幸自己能夠牽頭做這件事,經過研究實現元件化的通訊方案通過URL Scheme,所以想著現在還是在預研階段,很有必要先了解一下URL Scheme,看看是如何使用的?其實在之前做Hybrid混合程式設計的時候就接觸過URL Scheme,總來的來說還不算陌生,今天就來回顧總結一下。業務元件化相關部落格地址(Android業務元件化之現狀分析與探討)
業務元件化相關文章地址:
什麼是 URL Scheme?
android中的scheme是一種頁面內跳轉協議,是一種非常好的實現機制,通過定義自己的scheme協議,可以非常方便跳轉app中的各個頁面;通過scheme協議,伺服器可以定製化告訴App跳轉那個頁面,可以通過通知欄訊息定製化跳轉頁面,可以通過H5頁面跳轉頁面等。
URL Scheme應用場景:
客戶端應用可以向作業系統註冊一個 URL scheme,該 scheme 用於從瀏覽器或其他應用中啟動本應用。通過指定的 URL 欄位,可以讓應用在被調起後直接開啟某些特定頁面,比如商品詳情頁、活動詳情頁等等。也可以執行某些指定動作,如完成支付等。也可以在應用內通過 html 頁來直接呼叫顯示 app 內的某個頁面。綜上URL Scheme使用場景大致分以下幾種:
- 伺服器下發跳轉路徑,客戶端根據伺服器下發跳轉路徑跳轉相應的頁面
- H5頁面點選錨點,根據錨點具體跳轉路徑APP端跳轉具體的頁面
- APP端收到伺服器端下發的PUSH通知欄訊息,根據訊息的點選跳轉路徑跳轉相關頁面
- APP根據URL跳轉到另外一個APP指定頁面
URL Scheme協議格式:
先來個完整的URL Scheme協議格式:
xl://goods:8888/goodsDetail?goodsId=10011002
通過上面的路徑 Scheme、Host、port、path、query全部包含,基本上平時使用路徑就是這樣子的。
- xl代表該Scheme 協議名稱
- goods代表Scheme作用於哪個地址域
- goodsDetail代表Scheme指定的頁面
- goodsId代表傳遞的引數
- 8888代表該路徑的埠號
URL Scheme如何使用:
1.)在AndroidManifest.xml中對<activity />標籤增加<intent-filter />設定Scheme
<activity android:name=".GoodsDetailActivity" android:theme="@style/AppTheme"> <!--要想在別的App上能成功調起App,必須新增intent過濾器--> <intent-filter> <!--協議部分,隨便設定--> <data android:scheme="xl" android:host="goods" android:path="/goodsDetail" android:port="8888"/> <!--下面這幾行也必須得設定--> <category android:name="android.intent.category.DEFAULT"/> <action android:name="android.intent.action.VIEW"/> <category android:name="android.intent.category.BROWSABLE"/> </intent-filter> </activity>
2.)獲取Scheme跳轉的引數
Uri uri = getIntent().getData(); if (uri != null) { // 完整的url資訊 String url = uri.toString(); Log.e(TAG, "url: " + uri); // scheme部分 String scheme = uri.getScheme(); Log.e(TAG, "scheme: " + scheme); // host部分 String host = uri.getHost(); Log.e(TAG, "host: " + host); //port部分 int port = uri.getPort(); Log.e(TAG, "host: " + port); // 訪問路勁 String path = uri.getPath(); Log.e(TAG, "path: " + path); List<String> pathSegments = uri.getPathSegments(); // Query部分 String query = uri.getQuery(); Log.e(TAG, "query: " + query); //獲取指定引數值 String goodsId = uri.getQueryParameter("goodsId"); Log.e(TAG, "goodsId: " + goodsId); }
3.)呼叫方式
網頁上
<a href="xl://goods:8888/goodsDetail?goodsId=10011002">開啟商品詳情</a>
原生呼叫
Intent intent = new Intent(Intent.ACTION_VIEW,Uri.parse("xl://goods:8888/goodsDetail?goodsId=10011002")); startActivity(intent);
4.)如何判斷一個Scheme是否有效
PackageManager packageManager = getPackageManager(); Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse("xl://goods:8888/goodsDetail?goodsId=10011002")); List<ResolveInfo> activities = packageManager.queryIntentActivities(intent, 0); boolean isValid = !activities.isEmpty(); if (isValid) { startActivity(intent); }
總結:
Scheme的基本使用也就這麼多了,其他的使用在以後用到的時候再做總結。
相關推薦
Android業務元件化之URL Scheme使用
前言: 最近公司業務發展迅速,單一的專案工程不再適合公司發展需要,所以開始推進公司APP業務元件化,很榮幸自己能夠牽頭做這件事,經過研究實現元件化的通訊方案通過URL Scheme,所以想著現在還是在預研階段,很有必要先了解一下URL Scheme,看看是如何使用的?其實在之前做Hybrid混合程
Android業務元件化之現狀分析與探討
前言: 從個人經歷來說的話,從事APP開發這麼多年來,所接觸的APP的體積變得越來越大,業務的也變得越來越複雜,總來來說只有一句話:這是一個APP臃腫的時代!所以為了告別APP臃腫的時代,讓我們進入一個U盤時代,每個業務模組都是一個具備獨立執行的U盤,插在哪
Android業務元件化之Gradle和Sonatype Nexus搭建私有maven倉庫
前言: 公司的業務元件化推進的已經差不多三四個月的時間了,各個業務元件之間的解耦工作已經基本完成,各個業務元件以module的形式存在專案中,然後專案依賴本地的module,多少有點不太利於專案的並行開發維護了,本質原因就是如果是依賴本地的,必須要將依賴的module和主工程放在一個project裡
Android業務元件化之子模組SubModule的拆分以及它們之間的路由Router實現
前言: 前面分析了APP的現狀以及業務元件化的一些探討(Android業務元件化之現狀分析與探討),以及通訊的橋樑Scheme的使用(Android業務元件化之URL Scheme使用),今天重點來聊下子模組SubModule的拆分以及它們之間的路由Router實現。本篇涉及的相關知識比較多,閱讀
Android 專案元件化之建立module,生成aar,引入aar
導言: 在android平時的開發中,經常自己寫的東西讓別人使用,那麼就有module,aar,jar等方式. 1:module通過import module並dependencies完成 2:aar,包括所有檔案的android專用包,通過右邊的gradle->assembl
Android 業務元件化開發實踐
本文原創,轉載請以連結形式註明地址:http://kymjs.com/code/2016/10/18/01元件化並不是新話題,其實很早很早以前我們開始為專案解耦的時候就討論過的。但那時候我們說的是功能元件化。比如很多公司都常見的,網路請求模組、登入註冊模組單獨拿出來,交給一個團隊開發,而在用的時候只需要接入對
Android業務元件化開發實踐
1. 寫在前面 原文地址:http://kymjs.com/code/2016/10/18/01 借用阿布倪盟博的一句話:“在MDCC中馮森林老師的《迴歸初心,從容器化到元件化》,為我們這些沒有那麼多精力折騰黑科技開發者們打開了另一扇門” 。 元件
Android業務元件化開發實踐(轉載)
借用阿布倪盟博的一句話:“在MDCC中馮森林老師的《迴歸初心,從容器化到元件化》,為我們這些沒有那麼多精力折騰黑科技開發者們打開了另一扇門” 。 元件化並不是新話題,其實很早很早以前我們開始為專案解耦的時候就討論過的。但那時候我們說的是功能元件化。比如很多公司都常
Android業務元件化開發實踐(二)
前言: 從個人經歷來說的話,從事APP開發這麼多年來,所接觸的APP的體積變得越來越大,業務的也變得越來越複雜,總來來說只有一句話:這是一個APP臃腫的時代!所以為了告別APP臃腫的時代,讓我們進入一個U盤時代,每個業務模組都是一個具備獨立執行的U盤,插在哪裡都可以完美執行,這就是推進業務元件
Android專案架構之業務元件化
前言: 從個人經歷來說的話,從事APP開發這麼多年來,所接觸的APP的體積變得越來越大,業務的也變得越來越複雜,總來來說只有一句話:這是一個APP臃腫的時代!所以為了告別APP臃腫的時代,讓我們進入一個U盤時代,每個業務模組都是一個具備獨立執行的盤,插在哪裡都
Android元件化之元件通訊
Demo地址:https://github.com/751496032/ComponentDemo 本文是續上一篇Android元件化方案實踐與思考文章一些思考,主要是針對元件間通訊,比如: 每個元件如何初始化各自的資料 Activity間如何跳轉、Fragment例項
我所理解的Android元件化之通訊機制
之前寫過一篇關於Android元件化的文章,《Android元件化框架設計與實踐》,之前沒看過的小夥伴可以先點選閱讀。那篇文章是從實戰中進行總結得來,是公司的一個真實專案進行元件化架構改造,粒度會分的更粗些,是對整體架構實踐進行相應的總結,裡面說了要打造一個元件化框架的話,需要從以下7個方面入手: 程式碼解
Android 元件化之路 路由設計
基於公司業務發展,公司的APP需求不斷增加,應用也略顯“臃腫”。想著趁現在不那麼“糟糕”,時間也比較寬裕,把專案結構整整,因而走上了元件化之路。 模組化 VS 元件化 模組化: 將一個程式按照其功能做拆分,分成相互獨立的模組,以便於每個模組只包含與其功能
Android元件化之終極方案
Fragment或View如何支援元件化 距離 Android元件化方案 釋出已經半年有餘,雖說這個方案已經能夠解決一些專案的需求,但是依然不夠完美。很多開發者也在部落格和GitHub中留言甚至發郵件問我,Fragment怎麼辦?
Android元件化之不同模組間 互動(activity互相跳轉,資料互相傳遞,互相呼叫函式)
轉載請標明地址:https://blog.csdn.net/gaolei1201/article/details/77601027 在元件化之前,業務發展不是很快的時候,這樣是比較合適的,能一定程度地保證開發效率。 慢慢地程式碼量多了起來,開發人員也多了起來,業務發展也
(一)Android官方MVVM框架實現元件化之整體結構
一、google官方MVVM框架講解 我前面對比了MVC和MVP《兩張圖看懂Android開發中MVC與MVP的區別》,可以相對於MVC我們的MVP是有多優越,但是Android開發現在已經開始流行了MVVM,前不久google官方釋出了MVV
Android業務組件化之Gradle和Sonatype Nexus搭建私有maven倉庫
Android 前言: 公司的業務組件化推進的已經差不多三四個月的時間了,各個業務組件之間的解耦工作已經基本完成,各個業務組件以module的形式存在項目中,然後項目依賴本地的module,多少有點不太利於項目的並行開發維護了,本質原因就是如果是依賴本地的,必須要將依賴
Android組件化之終極方案
string 問題 我想 ont 建倉 組織 net 直接 互聯網技術 Android組件化項目地址:Android組件化項目AndroidModulePattern Fragment或View如何支持組件化 如何管理組件 Fragment或View如何
IView元件化之部署
IView是什麼? iView 是一套基於 Vue.js 的開源 UI 元件庫,主要服務於 PC 介面的中後臺產品。 Npm安裝IView npm install iview 在main.js中配置Iview // The Vue build version to load
元件化之路—整合元件SDK
介紹 元件化的前提是要有基礎元件、功能元件、業務元件這三大塊。其中基礎元件和功能元件都可以做成SDK,可以供其他APP選擇性的呼叫。 比如把地圖元件單獨封裝成一個SDK,需要使用地圖就載入這個SDK,不需要使用的就不載入。對於全部封裝成一個公共庫的做法,這樣既能實現解耦,又可以減少包的大