Ⅰ 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哪个交互简单
都差不多。