Ⅰ web app與原生app有哪些交互設計區別
從使用場景上，Web App用戶面臨比原生APP用戶更嚴峻的問題：
1、頁面跳轉更加費力，不穩定感更強
思考點：如何減少跳轉（扁平結構、頁面布局技巧），增加數據及展示的流暢流程及穩定性（技術）
2、更小的頁面空間（由於瀏覽器的導航本身佔用一部分屏幕空間），更大的信息記憶負擔
移動設備的屏幕要小得多。這種如同透過門縫進行的閱讀增加了認知的負擔。人腦的短期記憶是不穩定的，用戶在滾動屏幕的過程中需要臨時記憶的信息越多，他們的表現就會越差。——《貼心設計：打造高可用性的移動產品》
思考點：排版更清晰、信息更簡練 （可在原生APP基礎上去掉一些豐富、復雜的視覺表現）
3、導航不明顯，原有底部導航消失，有效的導航遇到挑戰
思考點：如何有效的提供導航？有哪些形式？
4、交互動態效果收到限制，影響一些頁面場景、邏輯的理解。
思考點：比如登錄注冊流程的彈出、完成及異常退出，做好文字提示。
Ⅱ 讓WEB鏈接完美的跳轉到APP客戶端怎麼做
讓WEB鏈接完美的跳轉到APP客戶端怎麼做的解答如下
在一般情況下，這種跳轉優化根據設計的無縫度會有四種，總結如下（在此聲明，我所測試的所有App都是我個人比較喜歡的，所以不存在詆毀哪款產品問題）：
第一種：鏈接是為PC設計的，根本沒有針對移動設備進行過優化，打開鏈接你必須通過縮放才能看到網頁上的內容。這類App有很多，比如大眾點評、果殼、果庫、抬杠等。
第二種：鏈接為移動設備優化過，但從網頁端轉到移動端仍然有斷層。比如美樂時光官方微信會推薦一些歌單，我用瀏覽器打開後便可以直接播放，移動體驗非常棒，但即便登錄之後也不能對播放的歌曲進行收藏。如果我想收藏某些歌曲，必須用電腦打開網站，搜到歌曲，然後收藏後才會同步到美樂時光App上，非常的麻煩。另外這類App還有：想去、美團等。
這裡面還有一種情況，就是媒體類應用。由於媒體本身產生的內容只是一篇篇文章，所以很容易為移動設備優化。但這又分兩類，一類本身網頁在移動設備上的體驗非常好，同時也有客戶端，但兩者是有斷層的。第二類是對移動端進行了優化，但由於沒有客戶端，反而不會出現上體驗斷層的問題。
第三種：產品本身就是為移動而生的，即便是網頁版，也像移動端一樣簡潔。這種鏈接打開沒任何壓力，即便登錄，也是非常方便的。你可以直接用網頁版進行各種操作，然後打開App就能同步了。這種情況已經算是非常好的了，但它仍然無法解決網頁鏈接和App之間的鴻溝問題，我不能直接通過網頁鏈接打開App。這類產品比較少，比如早期的果庫（無網頁版）、國外的Fancy等。
第四種：點擊鏈接可以直接打開App，如果是在桌面端則直接在瀏覽器中顯示內容。在我測試的十幾款App中，我只發現了兩款在網頁鏈接向App跳轉上做得非常好，那就是啪啪（Papa）和Instagram。我在刷微博看見好友分享了一條啪啪時，點擊鏈接，我的啪啪就會自動打開，然後顯示好友分享的內容。而Instagram做法有些不同，它第一次打開的是優化過的網頁，然後Logo旁有一個「Open in app」的按鈕，點擊之後可以直接打開App。這樣就非常方便，如果我沒有安裝app，那麼它會直接在手機瀏覽器里打開，如果我用的是電腦，那它也會直接在桌面瀏覽器中打開。
Ⅲ Javaweb與安卓數據交互
你好推薦你看邵剛老師的javaWeb教程，在51cto就有，另外包括ssh的部分也可以看看。
Ⅳ 手機APP和web服務端 跨域問題
跨域問題來源於JavaScript的同源策略，即只有 協議+主機名+埠號 (如存在)相同，則允許相互訪問。也就是說JavaScript只能訪問和操作自己域下的資源，不能訪問和操作其他域下的資源。
在以前，前端和後端混雜在一起， 比如JavaScript直接調用同系統裡面的一個Httphandler，就不存在跨域的問題，但是隨著現代的這種多種客戶端的流行，比如一個應用通常會有Web端，App端，以及WebApp端，各種客戶端通常會使用同一套的後台處理邏輯，即API， 前後端分離的開發策略流行起來，前端只關注展現，通常使用JavaScript，後端處理邏輯和數據通常使用WebService來提供json數據。一般的前端頁面和後端的WebService API通常部署在不同的伺服器或者域名上。這樣，通過ajax請求WebService的時候，就會出現同源策略的問題。
需要說明的是，同源策略是JavaScript裡面的限制，其他的編程語言，比如在C#，Java或者iOS等其他語言中是可以調用外部的WebService，也就是說，如果開發Native應用，是不存在這個問題的，但是如果開發Web或者Html5如WebApp，通常使用JavaScript ajax對WebService發起請求然後解析返回的值，這樣就可能存在跨域的問題。
一般的，很容易想到，將外部的資源搬到同一個域上就能解決同源策略的限制的。即在Web網站上同時開發一個Http服務端頁面，所有JavaScript的請求都發到這個頁面上來，這個頁面在內部使用其他語言去調用外部的WebService。即添加一個代理層。這種方式可以解決問題，但是不夠直接和高效。
目前，比較常見的跨域解決方案包括JSONP (JSON with padding)和CORS (Cross-origin resource sharing )。一些解決方案需要客戶端和服務端配合如JSOP，一些則只需要服務端配合處理比如CORS。下面分別介紹這兩種跨域方案，以及服務端WebService如何支持這兩種跨域方案。
JSONP以及WebService的支持
同源策略下，某個伺服器是無法獲取到伺服器以外的數據，但是html裡面的img,iframe和script等標簽是個例外，這些標簽可以通過src屬性請求到其他伺服器上的數據。而JSONP就是通過script節點src調用跨域的請求。
當我們向伺服器提交一個JSONP的請求時,我們給服務傳了一個特殊的參數,告訴服務端要對結果特殊處理一下。這樣服務端返回的數據就會進行一點包裝，客戶端就可以處理。
舉個例子，服務端和客戶端約定要傳一個名為callback的參數來使用JSONP功能。比如請求的參數如下:
http://www.example.net/sample.aspx?callback=mycallback
如果沒有後面的callback參數，即不使用JSONP的模式，該服務的返回結果可能是一個單純的json字元串，比如：
{ foo : 'bar' }
如果和服務端約定jsonp格式，那麼服務端就會處理callback的參數，將返回結果進行一下處理，比如處理成：
mycallback({ foo : 'bar' })
可以看到，這其實是一個函數調用，比如可以實現在頁面定義一個名為mycallback的回調函數：
mycallback = function(data)
{
alert(data.foo);
};
現在，請求的返回值回去觸發回調函數，這樣就完了了跨域請求。
如果使用ServiceStack創建WebService的話，支持Jsonp方式的調用很簡單，只需要在AppHost的Configure函數裡面注冊一下對響應結果進行過濾處理即可。
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
ResponseFilters.Add((req, res, dto) =>
{
var func = req.QueryString.Get("callback");
if (!func.isNullOrEmpty())
{
res.AddHeader("Content-Type", ContentType.Html);
res.Write("<script type='text/javascript'>{0}({1});</script>"
.FormatWith(func, dto.ToJson()));
res.Close();
}
});
}
JSONP跨域方式比較方便，也支持各種較老的瀏覽器，但是缺點很明顯，他只支持GET的方式提交，不支持其他Post的提交，Get方式對請求的參數長度有限制，在有些情況下可能不滿足要求。所以下面就介紹一下CORS的跨域解決方案。
CORS跨域及WebService的支持
先來看一個例子，我們新建一個基本的html頁面，在裡面編寫一個簡單的是否支持跨域的小腳本，如下：
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>AJAX跨域請求測試</title>
</head>
<body>
<input type='button' value='開始測試' onclick='crossDomainRequest()' />
<div id="content"></div>
<script type="text/javascript">
//<![CDATA[
var xhr = new XMLHttpRequest();
var url = 'http://localhost:8078/json/ShopUserLogin';
function crossDomainRequest() {
document.getElementById("content").innerHTML = "開始……";
if (xhr) {
xhr.open('POST', url, true);
xhr.onreadystatechange = handler;
xhr.send();
} else {
document.getElementById("content").innerHTML = "不能創建 XMLHttpRequest";
}
}
function handler(evtXHR) {
if (xhr.readyState == 4) {
if (xhr.status == 200) {
var response = xhr.responseText;
document.getElementById("content").innerHTML = "結果：" + response;
} else {
document.getElementById("content").innerHTML = "不允許跨域請求。";
}
}
else {
document.getElementById("content").innerHTML += "<br/>執行狀態 readyState：" + xhr.readyState;
}
}
//]]>
</script>
</body>
</html>
然後保存為本地html文件，可以看到，這個腳本中，對本地的服務http://localhost:1337/json/Hello 發起了一個請求， 如果使用chrome 直接打開，會看到輸出的結果，不允許跨域請求。 在javascript控制台程序中同樣可以看到錯誤提示：
那麼如果在返回響應頭header中注入Access-Control-Allow-Origin，這樣瀏覽器檢測到header中的Access-Control-Allow-Origin，則就可以跨域操作了。
同樣，如果使用ServcieStack，在很多地方可以支持CORS的跨域方式。最簡單的還是在AppHost的Configure函數裡面直接寫入：
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
this.AddPlugin(new CorsFeature());
}
這樣就可以了，相當於使用默認的CORS配置：
CorsFeature(allowedOrigins:"*",
allowedMethods:"GET, POST, PUT, DELETE, OPTIONS",
allowedHeaders:"Content-Type",
allowCredentials:false);
如果僅僅允許GET和POST的請求支持CORS，則只需要改為：
Plugins.Add(new CorsFeature(allowedMethods: "GET, POST"));
當然也可以在AppHost的Config裡面設置全局的CORS，如下：
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
base.SetConfig(new EndpointHostConfig
{
GlobalResponseHeaders = {
{ "Access-Control-Allow-Origin", "*" },
{ "Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS" },
{ "Access-Control-Allow-Headers", "Content-Type" },
},
});
}
現在運行WebService，使用postman或者Chrome調用這個請求，可以看到返回的值頭文件中，已經加上了響應頭，並且可以正常顯示返回結果了：
CORS使用起來簡單，不需要客戶端的額外處理，而且支持Post的方式提交請求，但是CORS的唯一一個缺點是對客戶端的瀏覽器版本有要求，支持CORS的瀏覽器機器版本如下：
總結
本文介紹了JavaScript中的跨域基本概念和產生的原因，以及如何解決跨域的兩種方法，一種是JSONP 一種是 CORS,在客戶端Javascript調用服務端介面的時候，如果需要支持跨域的話，需要服務端支持。JSONP的方式就是服務端對返回的值進行回調函數包裝，他的優點是支持眾多的瀏覽器， 缺點是僅支持Get的方式對服務端請求。另一種主流的跨域方案是CORS，他僅需要服務端在返回數據的時候在相應頭中加入標識信息。這種方式非常簡便。唯一的缺點是需要瀏覽器的支持，一些較老的瀏覽器可能不支持CORS特性。
跨域支持是創建WebService時應該考慮的一個功能點，希望本文對您在這邊面有所幫助，文中是使用ServiceStack來演示跨域支持的，如果您用的WCF的話，知道跨域原理的前提下，實現跨域應該不難。
參考資料：
https://github.com/ServiceStack/ServiceStack/wiki/Customize-HTTP-Responses
https://github.com/ServiceStack/ServiceStack/wiki/Request-and-response-filters
http://stackoverflow.com/questions/8211930/servicestack-rest-api-and-cors
http://stackoverflow.com/questions/15224038/rename-callback-parameter-for-jsonp
Ⅳ APK與WEB交互問題
那得改app的代碼啊，把注冊鏈接改為你自己網站的，還得修改注冊相關內容，以符合你的網站的注冊要求；另外你網站的後台得提供相應的注冊介面，以給app調用。網站後台也得做二次開發。
Ⅵ app開發工作中。web前端工程師與ios。安卓。會進行什麼交互嗎
如果是做app H5 頁面嵌入到 ios，android 的程序中，頁面可能會需要 調用設備的 相機，錄音，播放。。。 很多設備功能。 網頁和程序之間交互可以使用開源的項目 Cordova 。詳情原理和使用請網路。
Ⅶ 從交互設計角度看web網站和app有哪些差異
注要是app可以做的界面比較美觀，web網站做的不太容易達到那個效果
Ⅷ App與Web網站的主要區別
從使用場景上，web
app用戶面臨比原生app用戶更嚴峻的問題：
1、頁面跳轉更加費力，不穩定感更強
思考點：如何減少跳轉（扁平結構、頁面布局技巧），增加數據及展示的流暢流程及穩定性（技術）。
2、更小的頁面空間（由於瀏覽器的導航本身佔用一部分屏幕空間），更大的信息記憶負擔；
移動設備的屏幕要小得多。這種如同透過門縫進行的閱讀增加了認知的負擔。人腦的短期記憶是不穩定的，用戶在滾動屏幕的過程中需要臨時記憶的信息越多，他們的表現就會越差。——《貼心設計：打造高可用性的移動產品》
思考點：排版更清晰、信息更簡練
（可在原生app基礎上去掉一些豐富、復雜的視覺表現）
3、導航不明顯，原有底部導航消失，有效的導航遇到挑戰
思考點：如何有效的提供導航？有哪些形式？
4、交互動態效果收到限制，影響一些頁面場景、邏輯的理解。
思考點：比如登錄注冊流程的彈出、完成及異常退出，做好文字提示。
區別：app屬於手機應用客戶端，移動網站可以製作成app，app也可以呈現手機網站。
相同點：二者都屬於手機系列
區別在於：app可以安裝到手機上，而移動網站只能通這用戶打開網址才能打開了解信息。如果移動網站設計成app，則二者兼合。
Ⅸ 微信公眾平台如何與Web App結合
微信公眾平台與app資料庫對接需要開啟微信的開發者模式，然後進行技術對接就可以了，微信採用移動web頁面設計，設計完以後與app的資料庫進行對接就可以了
你想用微信實現什麼功能，只是實現指令交互，沒必要作微站，只需要開發連接app資料庫進行對接指令即可，如果需要和app一樣實現頁面話顯示，則需要開發微站進行輔助，如果你們沒有技術的話這個肯定是完成不了的，這中間需要編程。
Ⅹ app和web哪個交互簡單
都差不多。